home *** CD-ROM | disk | FTP | other *** search
/ Cream of the Crop 1 / Cream of the Crop 1.iso / PROGRAM / TP032292.ARJ / 03-22-92.TPC
Text File  |  1992-03-22  |  151KB  |  4,300 lines

  1.  
  2. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3.  
  4. Conference 4
  5. Date       03-15-92 06:53:26
  6. From       Trevor Carlsen
  7. To         Derek Westcott
  8. Subject    Tp 6.0 Ide
  9.  
  10.  
  11.  
  12.  DW> I have to disagree with you on that one.  The IDE provides at least 
  13.  DW> one necessary debugging feature - location of runtime errors in the 
  14.  DW> code...
  15.  
  16. That is available in any good programming editor - not just the IDE.
  17.  
  18.  DW> Outside in DOS, all you get is a meaningless address...when you 
  19.  DW> load up something to find that address, you've got to rerun the code 
  20.  
  21.  DW> under the finder utility...
  22.  
  23. You would appear not to have used Brief, VEdit, Multi-Edit, Unity, QEdit etc.
  24. etc. when they are properly set up.
  25.  
  26. TeeCee
  27.  
  28.  
  29.  
  30. --- TC-ED   v2.01  
  31.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  32.  * Tossed by SFToss v1.00b on 92/03/15  15:45:21
  33.  
  34. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  35.  
  36. Conference 4
  37. Date       03-15-92 07:58:00
  38. From       Trevor Carlsen
  39. To         Jud Mccranie
  40. Subject    Re: New Reader!
  41.  
  42.  
  43.  
  44.  JM> I'm pround of the fact that I've never used assembler, 
  45.  JM> and I probably never will...
  46.  
  47. Fine... however there are occasions when such an attitude is going to result
  48. in bloated and/or slower code than is otherwise necessary.  To my way of thinkin
  49.  a serious programmer has to make use of every possible tool or means at his/her
  50. disposal to produce product that is professional and slick.  Restricting yoursel
  51.  in the way you state will prevent that final polish.
  52.  
  53.  JM> I wish that was true foe me too, however I know for 
  54.  JM> sure at least 2 are currently using 8088.
  55.  
  56. I now restrict myself to coding *only* for '286 or better machines.  Now before
  57. all those out there scream and say how silly that is, I am in a situation
  58. totally different to most and therefore such a policy works for me.  For most
  59. people, and obviously this applies to you, it wouldn't be possible.  However
  60. nothing stops you producing two versions.
  61.  
  62.  JM> Because a major program needs the IDE MORE than a Q&D.  Fast
  63.  JM> compilation/editing/debugging.  The integrated debugger is a
  64.  JM> fantastic tool that you don't have anything remotely
  65.  JM> comperable (that I know ov) anywhere else.
  66.  
  67. I agree... it is a fantastic tool.  However the point I make is that it is
  68. not really necessary to forego this.  TD is more powerful and, given the right
  69. setup with a programmer's editor, almost as easy to use.  
  70.  
  71. How do you use the integrated debugger so frequently that "almost" becomes
  72. a problem?  My work style involves debugging small units thoroughly and then
  73. any major problem is in new work. As you can't use assembler, the ID's lack
  74. of a disassembler would not be as important to you as it is to me.  The disassem
  75. led code is a great way of seeing faults in your high-level code.
  76.  
  77. Another couple of points I would raise is your design method. It appears from
  78. your comments that your big work is developed in an ad hoc way.  If I am wrong
  79. please don't be offended by this comment, the reason I say this is because
  80. of comments I see from you about several updates per week, constant use of
  81. the debugger, not being aware of the uses and value of exit procedures etc.  
  82.  
  83. What is your big application used for and how many pages of documentation
  84. (particularly the user manual) are involved?  
  85.  
  86. In any big project the design stage is by far the hardest, longest and most
  87. important.  Normally most houses would budget on this stage taking  60-80%
  88. of the total project time.  Coding and obvious debugging probably represents
  89. less than 20% of the time and effort with the remainder being in-house testing
  90. and acceptance testing and ironing out any bugs this uncovers.  By design
  91. stage I mean analysis, functional specifications, general design (screen layouts
  92. and design, program modules, flow etc.), user manu
  93. als and test specifications. Only after this is done, and done properly, is
  94. any coding done.  Obviously, as coding proceeds there may be some minor cosmetic
  95. changes needed but any major hitch at this stage requires a proper procedure
  96. for handling this to be implemented.
  97.  
  98. TeeCee
  99.  
  100. --- TC-ED   v2.01  
  101.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  102.  * Tossed by SFToss v1.00b on 92/03/15  15:45:21
  103.  
  104. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  105.  
  106. Conference 4
  107. Date       03-15-92 07:40:24
  108. From       Trevor Carlsen
  109. To         Jud Mccranie
  110. Subject    Re: Tp 6.0 Ide
  111.  
  112.  
  113.  
  114.  JM> I disagree on the last part.  If I test in the IDE with range check
  115.  JM> on, then the only thing that can cause it to run differently as an
  116.  JM> EXE is an unitialized variable.  And that could make it run
  117.  JM> differently on different runs whether it was in the IDE or an EXE, as
  118.  JM> far as I know.  
  119.  
  120. In any testing a fundamental rule involves testing the limits, upper and lower,
  121. of all data.  This involves stack limits, heap limits, the whole works.  In
  122. the IDE it would be difficult, if not impossible to do this properly.  TSRs
  123. and ISRs cannot really be tested at all from the IDE unless you are fond of
  124. rebooting!
  125.  
  126. TeeCee
  127.  
  128. --- TC-ED   v2.01  
  129.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  130.  * Tossed by SFToss v1.00b on 92/03/15  15:45:21
  131.  
  132. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  133.  
  134. Conference 4
  135. Date       03-15-92 09:12:51
  136. From       Trevor Carlsen
  137. To         Jud Mccranie
  138. Subject    Re: New Reader!
  139.  
  140.  
  141.  
  142.  TC> Nothing stops you producing two versions.
  143.  
  144.  JM> I send out 1 or 2 new versions a week.  Not worth it for the cunfusion
  145.  JM> for such a small benefit.
  146.  
  147. Are you serious?  
  148.  
  149.  TC> I don't think I am aware of ONE thing that they cannot do that
  150.  TC> the IDE does (apart from display a Borland Copyright notice :-)
  151.  TC> ), and they have MANY functions not available in the IDE - some
  152.  TC> insignificant but some really major.
  153.  
  154.  JM> Do they have the integrated debugger?  Case closed.
  155.  
  156. No they don't... but the case is not closed.  Good design should minimise
  157. the use of the debugger to only the relatively harder bugs.  Then TD comes
  158. into its own.  And it is still only one keypress away.
  159.  
  160.  
  161. TeeCee
  162.  
  163. --- TC-ED   v2.01  
  164.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  165.  * Tossed by SFToss v1.00b on 92/03/15  15:45:22
  166.  
  167. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  168.  
  169. Conference 4
  170. Date       03-15-92 09:18:13
  171. From       Trevor Carlsen
  172. To         Jud Mccranie
  173. Subject    Re: Longer files in TP5
  174.  
  175.  
  176.  
  177.  TC> The TP5 IDE is severely crippled.  The TP6 IDE will allow you
  178.  TC> to edit large files and its help system is significantly larger
  179.  TC> and better than that in TP5. (Mind explaining why you consider
  180.  TC> the help system to be inferior?)
  181.  
  182.  JM> He shouldn't be using single files that large anyway.  ...
  183.  
  184. Why?  I agree that the source code should never approach that size in a normal
  185. situation but it is normal to expect that comments and documentation in the
  186. source file to exceed the actual source size.  Also there are *many* times
  187. you will want to load and read/edit much larger files that may not actually
  188. be part of the program.
  189.  
  190. TeeCee
  191.  
  192. --- TC-ED   v2.01  
  193.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  194.  * Tossed by SFToss v1.00b on 92/03/15  15:45:22
  195.  
  196. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  197.  
  198. Conference 4
  199. Date       03-15-92 09:22:43
  200. From       Trevor Carlsen
  201. To         Jud Mccranie
  202. Subject    Re: Pascal, The Language
  203.  
  204.  
  205.  
  206.  TC> Power and flexibility are usually mutually exclusive and
  207.  TC> therefore should not be grouped together like that.  Assembler
  208.  TC> is *by far* the most powerful language one can use.  NOTHING
  209.  TC> comes a close second.
  210.  
  211.  JM> You are equating Power to speed of execution and size of the
  212.  JM> EXE, I beleive.  ...
  213.  
  214. Not completely.  I define power as the ability of a language to do something.
  215.  There is nothing that can be done in a high level langauge that cannot be
  216. done with assembler, albeit it with more difficulty.  The reverse does not
  217. apply, therefore assembler is the more powerful.
  218.  
  219.  JM> ... Try expressing a complex algorithm in assembler
  220.  JM> and see how powerful it is. 
  221.  
  222. I didn't say "it is easier to do in assembler", I said it is by far the most
  223. powerful.  High level languages are primarily there to help the programmer
  224. avoid the drudgery and difficulties of using assembler.  The power of a language
  225. is not how easy it is for a programmer to achieve something in that language
  226. but how efficient and capable the language is in executing that something.  
  227.  
  228.  
  229. TeeCee
  230.  
  231. --- TC-ED   v2.01  
  232.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  233.  * Tossed by SFToss v1.00b on 92/03/15  15:45:22
  234.  
  235. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  236.  
  237. Conference 4
  238. Date       03-15-92 09:31:16
  239. From       Trevor Carlsen
  240. To         Kevin Higgins
  241. Subject    Run Time Error 162
  242.  
  243.  
  244.  
  245.  KH> Is there anything thing I could do in my code which would
  246.  KH> cause a run time error 162 (hardware failure)? I got a
  247.  KH> report of this from a beta tester on a program after I
  248.  KH> implemented the sort routine you helped me with (it works
  249.  KH> fine on most machines -- this may be an isolated instace,
  250.  KH> but the guy's system is sound...) Using the program with my
  251.  KH> old, inefficient sort, it works fine, but with the new quick
  252.  KH> sort you showed me he gets this error.... anything come to
  253.  KH> mind?
  254.  
  255. Without being able to get my hands on the program I could not tell.  I would
  256. suspect some kind of memory overwrite.  By memory the routine I supplied you
  257. with could do this, even with range checking enabled, so you need to be absolute
  258. y sure of preventing out-of-range errors.
  259.  
  260. All the usual caveats apply, watch unitialised pointers, single step through
  261. in the debugger etc. etc.
  262.  
  263. TeeCee
  264.  
  265. --- TC-ED   v2.01  
  266.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  267.  * Tossed by SFToss v1.00b on 92/03/15  15:45:23
  268.  
  269. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  270.  
  271. Conference 4
  272. Date       03-15-92 09:37:57
  273. From       Trevor Carlsen
  274. To         Thomas Groff
  275. Subject    Mucking about with disk files.
  276.  
  277.  
  278.  
  279.  TG> I recently saw a message someone posted asking how to slip some
  280.  TG> data into the start of a file that already contained data and
  281.  TG> it got me to thinking about disk files in general.
  282.  TG> Wouldn't it be possible to: 1. create a file containing new data.
  283.  TG> 2. delete an old file (The one you want to append.)
  284.  TG> 3. twiddle the disk's file allocation table and directory entry to
  285.  TG>    use disk space occupied by the erased file for the new file.
  286.  TG> 4. reopen the new file and push the file pointer to include the
  287.  TG>    erased files data.
  288.  
  289. I'd forget that idea very quickly if I were you!  It would only work if the
  290. data to be added exactly matched the size of a cluster and even then would
  291. be tricky and dangerous.  Not worth the effort.
  292.  
  293.  TG> Has anyone tried this?  Or does DOS not allow one to specify
  294.  TG> Just what disk area is going to be used next.
  295.  
  296. No and no.
  297.  
  298. TeeCee
  299.  
  300. --- TC-ED   v2.01  
  301.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  302.  * Tossed by SFToss v1.00b on 92/03/15  15:45:23
  303.  
  304. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  305.  
  306. Conference 4
  307. Date       03-15-92 09:42:31
  308. From       Trevor Carlsen
  309. To         Robert Kantor
  310. Subject    Help!
  311.  
  312.  
  313.  
  314.  RK> I am trying to utilize a two dimensional array.  The first field will 
  315.  
  316.  RK> contain numbers the second a string of 12 characters.  Does anyone 
  317.  RK> have a routine which will take the first field (numbers) and sort it 
  318.  
  319.  RK> and the corresponding strings will be sorted too?
  320.  
  321. Better that you use a singly dimmensioned array of records to achieve that.
  322.  
  323. type
  324.   YourRecord = record
  325.                  number : word;
  326.                  TheStr : string[12];
  327.                end;
  328.  
  329. var
  330.   YourArray : array[min..max] of YourRecord;
  331.  
  332. TeeCee
  333.  
  334. --- TC-ED   v2.01  
  335.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  336.  * Tossed by SFToss v1.00b on 92/03/15  15:45:23
  337.  
  338. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  339.  
  340. Conference 4
  341. Date       03-15-92 09:48:19
  342. From       Trevor Carlsen
  343. To         John Reid
  344. Subject    Archiver
  345.  
  346.  
  347.  
  348.  JR>  * SMRead 3.0  #0286 *  
  349.       ^                   ^
  350.  
  351. John you may not be aware of it but your reader/editor is placing hi-bit charact
  352. rs in the indicated positions.  Please fix if possible.
  353.  
  354. Trevor Carlsen
  355. Moderator.
  356.  
  357.  
  358.  
  359. --- TC-ED   v2.01  
  360.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  361.  * Tossed by SFToss v1.00b on 92/03/15  15:45:23
  362.  
  363. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  364.  
  365. Conference 4
  366. Date       03-15-92 09:53:01
  367. From       Trevor Carlsen
  368. To         Andrew Broughton
  369. Subject    Variable-Length Records
  370.  
  371.  
  372.  
  373.  AB> Does anyone out there know of a (fast) way to get to a specific record 
  374.  
  375.  AB> in a file that has variable-length records? What I have is a file with 
  376.  
  377.  AB> sorted records, each ending in the same terminator, but of varying 
  378.  AB> length. What I want to do is be able to do a binary search on the 
  379.  AB> file, but I need a way to
  380.  AB> jump to specific records.
  381.  
  382. It is simple to do by creating an index file.  Do this by reading through
  383. the file and recording in the index file the location of each terminator.
  384.  If this is still not sufficient ask again.
  385.  
  386. TeeCee
  387.  
  388. --- TC-ED   v2.01  
  389.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  390.  * Tossed by SFToss v1.00b on 92/03/15  15:45:24
  391.  
  392. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  393.  
  394. Conference 4
  395. Date       03-15-92 10:01:22
  396. From       Trevor Carlsen
  397. To         Jud Mccranie
  398. Subject    Re: New Reader!
  399.  
  400.  
  401.  
  402.  RM> In some cases I have been required to use a particular editor
  403.  RM> to conform with team requirements, specifically with version
  404.  RM> control or standard metrics.  This is a contract stipulation
  405.  RM> that is common for commercial programmers.
  406.  
  407.  JM> Not to detailed specs.  They tell me what they want it to do and
  408.  JM> I do it.  Then if they want it changed I change it.  I don't have
  409.  JM> to conform to team requirements.
  410.  
  411. A 400k .exe is a big program and could easily represent man-years of effort
  412. by a programmer.  Such a program would be highly unlikely to be developed
  413. by a one-man show unless the major part of that 400k is taken up by third
  414. party library stuff.  As such and in total it probably still represents man
  415. years of effort.
  416.  
  417. I would not consider contracting a big job with someone who cannot either
  418. provide detailed written specifications or alternatively sit down with me,
  419. or a team, and come up with those detailed specifications.  It is simply not
  420. viable to quote a price without that being done.  And if I could find someone
  421. stupid enough to contract me to do a big project on an hourly basis, I would
  422. be in seventh heaven.  Successful businesses do not do that sort of thing!
  423.  
  424.  JM> Well, I can bet that if the program will fit in the TP IDE, I can
  425.  JM> develop faster and better than anyone using Brief, QEdit, etc because
  426.  JM> of the power of the integrated debugger.
  427.  
  428. I can place only one interpretation on that statement and that is that you
  429. develop "as you go".  On smaller or unimportant jobs I guess that many of
  430. us work that way and that would definitely make the ID a more important factor.
  431. (I know that too often I work that way thinking that I can get away with the
  432. slackness because of the nature of the task.)  On serious jobs though, that
  433. method will produce poor code and poorer programs, necessitating frequent
  434. revisions due to simple bugs or unplanned improvements.  I would be willing
  435. to bet many dollars on a professsional programmer with a professional editor
  436. and professional set of tools being more productive than if he was using the
  437. IDE and the same tools.
  438.  
  439. TeeCee
  440.  
  441. --- TC-ED   v2.01  
  442.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  443.  * Tossed by SFToss v1.00b on 92/03/15  15:45:24
  444.  
  445. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  446.  
  447. Conference 4
  448. Date       03-15-92 13:31:17
  449. From       Trevor Carlsen
  450. To         Jud Mccranie
  451. Subject    Re: New Reader!
  452.  
  453.  
  454.  
  455.  DM> I'm sort of curious why you'd be proud never to have used a
  456.  DM> useful tool, but it's hardly a Pascal topic, so I won't ask.
  457.  
  458.  JM> Because I use only high-level languages.  I write app progs, not
  459.  JM> utilites or system progs.  As far as speed, it is often easier to
  460.  JM> write a fast one in a high-level language than assembler.  For
  461.  JM> instance, an average version of quicksort in Pascal will easily
  462.  JM> outrun a tight assembler implementation of bubblesort.
  463.  
  464. Of course it is and of course it will!  But you are comparing a Ferrari towing
  465. a trailer to a small car.  Take the trailer off the Ferrari by using assembler
  466. AND a QuickSort and there is once again no contest.  Sorting and searching
  467. are excellent examples of code in ordinary everyday applications that benefit
  468. substantially by the use of assembler, substantially enough to make a significan
  469.  impact on the perception of the application by the end user.
  470.  
  471. TeeCee
  472.  
  473.  
  474. --- TC-ED   v2.01  
  475.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  476.  * Tossed by SFToss v1.00b on 92/03/15  15:45:24
  477.  
  478. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  479.  
  480. Conference 4
  481. Date       03-15-92 13:45:27
  482. From       Trevor Carlsen
  483. To         Jud Mccranie
  484. Subject    Re: Tp 6.0 Ide
  485.  
  486.  
  487.  
  488.  JM> I've never seen a case where the program rn differently in the
  489.  JM> IDE instead of EXE unless there was a dumb bug.
  490.  
  491. I'm not sure of this but do programs running in the IDE using the PrefixSeg
  492. variable operate correctly?  (I have no way of checking without re-installing
  493. the IDE)
  494.  
  495. TeeCee
  496.  
  497. --- TC-ED   v2.01  
  498.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  499.  * Tossed by SFToss v1.00b on 92/03/15  15:45:25
  500.  
  501. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  502.  
  503. Conference 4
  504. Date       03-15-92 13:48:44
  505. From       Trevor Carlsen
  506. To         Jim McNamee
  507. Subject    TP 6.0
  508.  
  509.  
  510.  
  511.  JM> One inclusion I've been waiting for is dynamic or conformant arrays.  
  512.  
  513.  
  514. It would be a nice addition even though it is easy enough to pseudo implement
  515. yourself using untyped parameters.  
  516.  
  517.  JM> At the moment, to pass array data to a Proc or Function one must 
  518.  JM> explicitely use pointers or sprinkle typed constants throughout .TPUs 
  519.  
  520.  JM> to assure that passed arguments are identical between called and 
  521.  JM> calling code.  
  522.  
  523. I feel that this is not quite correct if my above suggestion is used.
  524.  
  525.  JM> ... The ISO standard would allow determination of array 
  526.  JM> size at run-time allowing arrays to be passed more easily.
  527.  
  528. Undoubtedly.
  529.  
  530. TeeCee
  531.  
  532.  
  533.  
  534. --- TC-ED   v2.01  
  535.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  536.  * Tossed by SFToss v1.00b on 92/03/15  15:45:25
  537.  
  538. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  539.  
  540. Conference 4
  541. Date       03-15-92 13:54:45
  542. From       Trevor Carlsen
  543. To         Ken Koch
  544. Subject    IDE's
  545.  
  546.  
  547.  
  548.  KK>  I just downloaded an IDE called UNITY310. This program looks
  549.  KK>  great except for 1 thing. It does not let you specify the
  550.  KK>  multiple directories, like the default TP 5.5 IDE does. Like
  551.  KK>  setting up your include directories, or the object
  552.  KK>  directories, etc. Is there any other IDE out there that
  553.  KK>  provides this function.
  554.  
  555. Welcome to the club :-)  Your productivity will increase remarkably!  The
  556. problem you are having is not due to Unity but to your config file for TPC.
  557.  Set that up correctly and Voila!
  558.  
  559. TeeCee
  560.  
  561. --- TC-ED   v2.01  
  562.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  563.  * Tossed by SFToss v1.00b on 92/03/15  15:45:25
  564.  
  565. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  566.  
  567. Conference 4
  568. Date       03-15-92 13:58:55
  569. From       Trevor Carlsen
  570. To         Jud Mccranie
  571. Subject    Re: Pascal Vs. C
  572.  
  573.  
  574.  
  575.  DN> Sounds good. Is Modula 2 more or less low-level capable than
  576.  DN> TP?
  577.  
  578.  JM> Modula-2 is more low-level capable than Pascal...
  579.  
  580. True.  However if you were to say "Turbo Pascal" then I believe that the stateme
  581. t is incorrect.
  582.  
  583. TeeCee
  584.  
  585. --- TC-ED   v2.01  
  586.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  587.  * Tossed by SFToss v1.00b on 92/03/15  15:45:25
  588.  
  589. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  590.  
  591. Conference 4
  592. Date       03-15-92 14:10:13
  593. From       Trevor Carlsen
  594. To         Mark Sandfox @ 970/201
  595. Subject    Memory
  596.  
  597.  
  598.  
  599.  MS>   I have a large source code 400k+ that I can not compile.  I keep 
  600.  MS> recieving segment too large...
  601.  
  602. What is the actual error message?  Read the manual for information on the
  603. actual error message you are receiving.
  604.  
  605. TeeCee
  606.  
  607.  
  608.  
  609. --- TC-ED   v2.01  
  610.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  611.  * Tossed by SFToss v1.00b on 92/03/15  15:45:25
  612.  
  613. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  614.  
  615. Conference 4
  616. Date       03-15-92 14:13:47
  617. From       Trevor Carlsen
  618. To         Mark Sandfox @ 970/201
  619. Subject    Files
  620.  
  621.  
  622.  
  623.  MS> How can I make a data file unreadable to the user?  Besides 
  624.  MS> incription.
  625.  
  626. Probably encryption is your only means available.
  627.  
  628. TeeCee
  629.  
  630. --- TC-ED   v2.01  
  631.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  632.  * Tossed by SFToss v1.00b on 92/03/15  15:45:26
  633.  
  634. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  635.  
  636. Conference 4
  637. Date       03-15-92 16:06:20
  638. From       Trevor Carlsen
  639. To         James Digiacomo
  640. Subject    Dynamic Arrays in Turbo Pascal
  641.  
  642.  
  643.  
  644.  JD> the problem occurs when I try to display the contents stored in this 
  645.  
  646.  JD> type of array. it seem to contain the data PLUS additional garbage 
  647.  JD> characters. As a reminder, it only happens when I compile my program
  648.  
  649.  JD> here's the declaration part of my program:
  650.  
  651.  JD> TYPE
  652.  JD>      item = string;
  653.  JD>      limittype = array [1..1] of item;
  654.  JD>      numbertype= array [1..1] of item;
  655.  
  656.  JD> VAR
  657.  JD>      Lim : ^limittype;
  658.  JD>      temp, numbers : ^numbertype;
  659.  
  660.  JD> I use TP's GETMEM procedure to allocate the memory for these arrays 
  661.  JD> and after the program is finished, I release the allocated memory 
  662.  JD> using the procedure
  663.  JD> FREEMEM.
  664.  
  665. You have not indicated the actual allocation and deallocation. That is the
  666. important part.  Also show some examples of reading and assigning array element
  667. values.
  668.  
  669. TeeCee
  670.  
  671. --- TC-ED   v2.01  
  672.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  673.  * Tossed by SFToss v1.00b on 92/03/15  15:45:26
  674.  
  675. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  676.  
  677. Conference 4
  678. Date       03-15-92 16:09:17
  679. From       Trevor Carlsen
  680. To         Bill Pantoja
  681. Subject    Re: Files
  682.  
  683.  
  684.  
  685.  BP> If you wirte a fast encryption scheme (Other then a simple
  686.  BP> NOT or XOR encryption), you can encrypt a 200MB file in
  687.  BP> under 30 seconds.
  688.  
  689. I simply  refuse to believe that this is possible.  That represents 6.67 megabyt
  690. s per second.  On a 486 33mHz even a simple no content loop does not execute
  691. that fast.  eg
  692.   for x := 1 to 200000000 do; 
  693. will take longer than 30 seconds.  On top of that you have all the necessary
  694. [slow] disk accesses.
  695.  
  696.  BP> program I wrote for the Medical Board Of California, all the
  697.  BP> data file were required to have a bullet-proof encryption
  698.  BP> scheme.  Using a combination of NOT, random translation
  699.  BP> tables, etc. I came up with a very good encryption scheme
  700.  BP> which uses a negligable amount of time.  The data file is
  701.  BP> over 2.7MB but by encrypting or decrypting the data in
  702.  BP> memory rather then on disk, it speeds up the program and
  703.  BP> protects against leaving the data "bare" on your disk if a
  704.  BP> user reboots the machine.
  705.  
  706. About the only "bullet proof" encryption is what is known as a "one time pad"
  707. method.  The encryption standard used by the US department of defense has
  708. so far defied attempts to break it but no mathematical proof exists of it
  709. being impossible.  It is also very slow on a PC.
  710.  
  711. Encryption of sensitive data can be made *almost* impossible to break without
  712. recourse to heavy duty computer usage/power and plenty of time, skill and
  713. imagination.  Non military or diplomatic data is rarely sufficiently valuable
  714. to make the effort worth the expense and even then then time constraints may
  715. defeat it.
  716.  
  717. TeeCee
  718.  
  719. --- TC-ED   v2.01  
  720.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  721.  * Tossed by SFToss v1.00b on 92/03/15  15:45:26
  722.  
  723. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  724.  
  725. Conference 4
  726. Date       03-15-92 20:11:08
  727. From       Trevor Carlsen
  728. To         Greg Williams
  729. Subject    Generating sequential file names...
  730.  
  731.  
  732.  
  733.  GW> Does anyone have an efficient method of generating the next filename 
  734.  
  735.  GW> in a sequence of names like the following:
  736.  
  737.  GW>         File000.ext
  738.  GW>         File001.ext
  739.  GW>         File002.ext
  740.  GW>         .
  741.  GW>         .
  742.  
  743.  GW> Where the number can be anything up to the whole eight characters 
  744.  GW> allowed for a filename (ie.  something like "00000231.ext")...
  745.  GW> Up to now, I've been asking DOS to pass me a "unique" filename, but 
  746.  GW> that is no good if you want to see at a glance which is the latest...
  747.  
  748. Keep the next number + 100000000 in the sequence as a longint in a file and
  749. just use TP's str procedure to produce the file name.
  750.  
  751. var
  752.   fname : string;
  753.   fnumber : longint;
  754.  
  755.   str(fname,fnumber);
  756.   fname := copy(fname,2,8) + '.' + ext;
  757.  
  758. TeeCee
  759.  
  760.  
  761.  
  762. --- TC-ED   v2.01  
  763.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  764.  * Tossed by SFToss v1.00b on 92/03/15  15:45:27
  765.  
  766. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  767.  
  768. Conference 4
  769. Date       03-16-92 06:27:03
  770. From       Trevor Carlsen
  771. To         Scott Hutchinson
  772. Subject    Hiya
  773.  
  774.  
  775.  
  776.  SH>  randomize;
  777.  SH>  writeln(random(1000));
  778.  
  779.  SH> This will generate a random number between 1 and 1000.  If you want it 
  780.  
  781.  SH> to generate a number on a larger scale, use a number larger than 1000. 
  782.  
  783.  SH>  If you have any more questions, I'll be glad to answer them for you.
  784.  
  785. Thanks...but try to answer them accurately! :-)
  786.  
  787. The above will display a random number ranging from 0 to 999.
  788.  
  789. TeeCee
  790.  
  791. --- TC-ED   v2.01  
  792.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  793.  * Tossed by SFToss v1.00b on 92/03/16  19:51:36
  794.  
  795. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  796.  
  797. Conference 4
  798. Date       03-16-92 16:22:49
  799. From       Trevor Carlsen
  800. To         Jud Mccranie
  801. Subject    Re: Pascal Structure Philosophy
  802.  
  803.  
  804.  
  805.  JM> In the example he gave, he doesn't have to set the variable, and that
  806.  JM> is one of his main points.  The variable is not checked until the end.
  807.  JM> The "error" variable is set automatically when the file is opened.
  808.  
  809. The only time it makes any difference is at the start of the looping construct
  810. and therefore it is of little or no consequence.  The easiest way is to start
  811. the loop by an if statement and then place both checks at the end of a repeat
  812. loop.  That way he avoids the required setting of the variable that he dislikes,
  813. code size is identical and execution time is probably the same.
  814.  
  815. To set up a completely new and unnecessary looping construct is a strange
  816. attitude.
  817.  
  818. TeeCee
  819.  
  820. --- TC-ED   v2.01  
  821.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  822.  * Tossed by SFToss v1.00b on 92/03/16  19:51:36
  823.  
  824. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  825.  
  826. Conference 4
  827. Date       03-16-92 17:33:47
  828. From       Trevor Carlsen
  829. To         Jud Mccranie
  830. Subject    TP 6 Bad design
  831.  
  832.  
  833.  
  834.  JM> First is execution speed.  I believe I have the same options in
  835.  JM> both, as far as checks, alignment, etc, however, I got the following
  836.  JM> results on the exact same source:
  837.  
  838.  JM> TP 5.5    22.24 seconds
  839.  JM> TP 6   G- 22.90
  840.  JM> TP 6   G+ 22.91
  841.  
  842.  JM> 286 instructions made no difference, and 5.5 executes 3% faster than
  843.  JM> either of of them.  Maybe I've done something different, but I don't
  844.  JM> think so.  (I'm using Eagle's system on both.)
  845.  
  846. I decided to set up the TP6 IDE again so I could test this.  Obviously I cannot
  847. comment on the actual results of yours as I don't know what your code was.  
  848.  
  849.  
  850. As you have stated elsewhere that all your testing is done in the IDE, the
  851. above would be an invalid test if that is the method you used in your testing.  
  852.  
  853.  
  854. The TP6 IDE is an event driven environment and unless it releases ALL hooks
  855. for that environment when executing a program from within itself, which I
  856. do not think it does, a certain amount of time is needed to service those
  857. hooks.  Because of this it is obvious, or should be to an experienced programmer
  858.  that a program running from within the TP6 IDE will always be slower than
  859. when the same code is executed from the command line.  That is exactly how
  860. it turned out in my testing.
  861.  
  862. In the test my test program was 9% slower running in the TP6 IDE than when
  863. executing from the DOS command line.  It was about 7.4% slower in the TP6
  864. IDE than when compiled with TP5.5 and run from the command line.  However
  865. when both versions were executed from the command line the TP6 version was
  866. about 1.7% faster than the TP5.5 version.
  867.  
  868. I was unable to do a test running from within the TP5.5 IDE but I would have
  869. thought a 3% figure might have been a little on the low side.  I think that
  870. the TP5 IDE hooks some vectors also, perhaps the discrepancy may be there,
  871. although without me running exactly the same set up as you it is a little
  872. pointless to compare my results to yours. Suffice it to say that bench mark
  873. testing from within different IDEs is invalid and I am very surprised that
  874. someone with your stated experience and knowledge would do that (if in fact
  875. you did, as appears likely from your results).
  876.  
  877. TeeCee
  878.  
  879. --- TC-ED   v2.01  
  880.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  881.  * Tossed by SFToss v1.00b on 92/03/16  19:51:36
  882.  
  883. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  884.  
  885. Conference 4
  886. Date       03-16-92 15:40:52
  887. From       Trevor Carlsen
  888. To         Gene Buckle
  889. Subject    Re: Bbs Source.. / Range Checking
  890.  
  891.  
  892.  
  893.  GB> ... I am getting a range check error on one of his functions
  894.  GB> that returns a boolean value.  I dies at "GetLogin := rcs"
  895.  GB> where rcs is boolean (and is set to true or false depending
  896.  GB> on what info is gathered in the body of the routine). It
  897.  GB> works just fine if I $R-, but with range checking on, it
  898.  GB> dies.
  899.  
  900. The easy way is to place the following lines immediately prior to the line
  901. in question -
  902.  
  903.   if (byte(rcs) <> 0) and (byte(rcs) <> 1) then begin
  904.     writeln('rcs has not been correctly initialised');
  905.     halt;
  906.   end;
  907.  
  908. I believe that you will find that rcs is not being initialised where you think
  909. it is - perhaps an if-then-else-if-then statement's logic is off or a value
  910. parameter is used where a reference parameter is needed.
  911.  
  912. Place a watch on it in the debugger to find out just when and how it is being
  913. initialised.  The result may surprise you.
  914.  
  915. TeeCee
  916.  
  917.  
  918. --- TC-ED   v2.01  
  919.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  920.  * Tossed by SFToss v1.00b on 92/03/16  19:51:37
  921.  
  922. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  923.  
  924. Conference 4
  925. Date       03-16-92 15:49:34
  926. From       Trevor Carlsen
  927. To         Gene Buckle
  928. Subject    Re: Bbs Source..
  929.  
  930.  
  931.  
  932.  GB> ... rcs is being initialized to FALSE at the beginning of the func.
  933.  
  934. Why not post the function?
  935.  
  936. TeeCee
  937.  
  938. --- TC-ED   v2.01  
  939.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  940.  * Tossed by SFToss v1.00b on 92/03/16  19:51:37
  941.  
  942. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  943.  
  944. Conference 4
  945. Date       03-15-92 16:21:00
  946. From       Werner Berghofer
  947. To         Jud McCranie
  948. Subject    Longer files in Turbo Pascal 5
  949.  
  950.  
  951.  
  952.  
  953.        Jud,
  954.  
  955.  > I con't consider TP 5 IDE "severely crippled" because of that.
  956.  > In fact, it is BETTER that the editor limit the files to 64K.
  957.  
  958.        no doubt about the second statement, you are right.  But how else than
  959. "severly crippled" would you call an editor which offers you Ctrl-Alt-Del
  960. as only option if during editing (block copying etc.) the size of a source
  961. file exceeds 64 KB?
  962.  
  963.        I'm very glad that Borland removed this not really seasonable editor
  964. limit in version 6.0 of Turbo Pascal.
  965.  
  966.        W.
  967.  
  968. ---
  969.  * Origin: God is real... unless declared integer. (2:310/90.100)
  970.  * Tossed by SFToss v1.00b on 92/03/17  04:34:44
  971.  
  972. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  973.  
  974. Conference 4
  975. Date       03-15-92 08:22:31
  976. From       Dj Murdoch
  977. To         Jud Mccranie
  978. Subject    Re: TP 6.0 IDE memory
  979.  
  980.   MO> BTW if you can't adapt to the 6.0 IDE, don't despair,
  981.  MO> Borland Pascal++ is just around the corner ;-)
  982.  
  983.  JM> That's what I've heard.  I hope they take the users into
  984.  JM> consideration this time.  They were headed in the wrong direction
  985.  JM> w/ 6.0 IDE, IMHO.
  986.  
  987. It's probably too late to make any difference now, but what sort of changes
  988. were you looking for?
  989.  
  990. --- Msg V3.2
  991.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  992.  * Tossed by SFToss v1.00b on 92/03/17  11:00:28
  993.  
  994. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  995.  
  996. Conference 4
  997. Date       03-15-92 08:25:12
  998. From       Dj Murdoch
  999. To         Dale Frakes
  1000. Subject    Re: Binary Tree Linked Lists
  1001.  
  1002.   > Actually B-Trees are more effecient than Binary tress and
  1003.  DF>  
  1004.  DF> I thought the B in B-tree stood for Binary.  What is the 
  1005.  DF> difference between a b-tree and a binary tree?  (Just a 
  1006.  DF> basic explanation, I don't want source and such).
  1007.  
  1008. B is for Balanced - to the extent possible, every node has the same number
  1009. of subnodes.  A binary tree can be so imbalanced as to be nearly a linked
  1010. list, if new nodes are always added on the right, for instance.
  1011.  
  1012. It's quite hard & time consuming to do adds & deletes to a balanced tree,
  1013. but the searches are fast.  A compromise method that allows easy adds and
  1014. deletes, but is 20 or 30 percent slower on searches, is a Skip List.  It's
  1015. a list with multiple indices:  there's one level that lists every node, the
  1016. next  level skips a few each step, the next one skips a few of those, etc.
  1017.  You start at the top level (fewest nodes) and do a linear search of 2 or
  1018. 3 nodes to find the starting place at the next level. 
  1019.  
  1020. The key thing that makes adds & deletes quick is that each new addition is
  1021. done completely independently of whatever is there.  You *randomly* choose
  1022. (according to a geometric distribution) how many levels a new addition should
  1023. fit into, and just add it to those. 
  1024.  
  1025. Look in the June 1990 issue of the Communications of the ACM for an article
  1026. discussing these, or look on PDN Pascal nodes for SKIPLIST.ZIP containing
  1027. some sample code. 
  1028.  
  1029. --- Msg V3.2
  1030.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1031.  * Tossed by SFToss v1.00b on 92/03/17  11:00:28
  1032.  
  1033. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1034.  
  1035. Conference 4
  1036. Date       03-15-92 08:37:04
  1037. From       Dj Murdoch
  1038. To         Ruurd Pels
  1039. Subject    Re: Turbo Vision Questions...
  1040.  
  1041.   RP> No sir it ain't! You are having a misconception about the 
  1042.  RP> nature of TV. It is not a collection of things. TV is a 
  1043.  RP> closely coupled class hierarchy containing a whole 
  1044.  RP> template program, ready to run. Apart from the TCollection 
  1045.  RP> class and it's descendants, it is ONE class hierarchy. 
  1046.  
  1047. And apart from the TStream class and its descendants, and the TStringList,
  1048. and the TResourceFile.  All of which are useful in programs that have nothing
  1049. descended from TView. 
  1050.  
  1051.  
  1052. --- Msg V3.2
  1053.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1054.  * Tossed by SFToss v1.00b on 92/03/17  11:00:28
  1055.  
  1056. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1057.  
  1058. Conference 4
  1059. Date       03-15-92 08:40:34
  1060. From       Dj Murdoch
  1061. To         Joshua Kersey @ 930/22
  1062. Subject    Re: Turbo Vision Questions...
  1063.  
  1064.   JK> Yes...but the fact remains that it still *IS* OOP, which 
  1065.  JK> I'm not good with and can hardly apply with a good spray 
  1066.  JK> bottle and a can of paste. I'd like to see Turbo Vision 
  1067.  JK> WITHOUT the OOP, something I could actually use without 
  1068.  JK> re-learning Pascal.
  1069.  
  1070. I can't imagine what TV without OOP would be.  Do you just mean a windowing
  1071. library?  There are lots of those.  The best would be Turbo Professional,
  1072. I've heard Turbo Technojock's Toolkit is good, and Blaise sells something.
  1073.  
  1074. --- Msg V3.2
  1075.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1076.  * Tossed by SFToss v1.00b on 92/03/17  11:00:28
  1077.  
  1078. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1079.  
  1080. Conference 4
  1081. Date       03-15-92 08:43:46
  1082. From       Dj Murdoch
  1083. To         Jud Mccranie
  1084. Subject    Re: Why I Like Tp 5.5 Ide (co
  1085.  
  1086.   JM> So the "O" should be BLACK - not cyan.  I look at "OK" and I think
  1087.  JM> the the hot letter should stand out.  In the other cases, the yellow
  1088.  JM> stands out from the black.  But in the case of "OK", with only two
  1089.  JM> letters (one cyan, one yellow), there is no way to tell which is
  1090.  JM> the hot letter unless you compare it to the rest of the screen, or
  1091.  JM> you rember "in that case, the yellow is the hot letter, and the
  1092.  JM> cyan one isn't" and the user shouldn't have to remember that.  He
  1093.  JM> should be able to tell at a glance which is the hot letter w/o having
  1094.  JM> to compate it with the rest of the screen or rember an arbitrary rule.
  1095.  
  1096. The trouble is that OK is special in two ways.  That's why it looks different
  1097. than any other button.  Seems smart to me...
  1098.  
  1099.  
  1100.  
  1101. --- Msg V3.2
  1102.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1103.  * Tossed by SFToss v1.00b on 92/03/17  11:00:28
  1104.  
  1105. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1106.  
  1107. Conference 4
  1108. Date       03-15-92 08:46:12
  1109. From       Dj Murdoch
  1110. To         Jud Mccranie
  1111. Subject    Re: TP 6 Bad design
  1112.  
  1113.   JM> I've been trying TP 6 again, and I've encountered even more
  1114.  JM> problems.
  1115.  
  1116.  JM> First, let me say that memory is no longer the hangup.  However,
  1117.  JM> everything else I've spoke of is still a problem, and I've
  1118.  JM> encountered several more pretty bad problems.
  1119.  
  1120.  JM> First is execution speed.  I believe I have the same options in
  1121.  JM> both, as far as checks, alignment, etc, however, I got the following
  1122.  JM> results on the exact same source:
  1123.  
  1124.  JM> TP 5.5    22.24 seconds
  1125.  JM> TP 6   G- 22.90
  1126.  JM> TP 6   G+ 22.91
  1127.  
  1128. $G+ can be slower than $G-, because of the bad implementation of ENTER and
  1129. LEAVE on the 80x86 family.  Borland should never have touched them.  That's
  1130. the only difference I would have expected.  Can you identify where the time
  1131. is being spent?
  1132.  
  1133.  JM> After you go through all of the tough song and dance to change an
  1134.  JM> option, if you don't OK it, the change doesn't take effect.  If
  1135.  JM> you F10 or escape from the menu w/o "OK"ing it, the change is lost.
  1136.  JM> This is an extremely bad design flaw.  The last thing you saw on
  1137.  JM> the screen should be the options in effect.
  1138.  
  1139. What do you mean "if you F10"?  That doesn't do anything in the menus on my
  1140. system.  The Escape behaviour is good, in my opinion.  After you've made a
  1141. pile of changes, it's nice to be able to accept them (Enter) or abandon them
  1142. (Esc).  Do you think it should ask if you really mean to abandon the changes?
  1143.  
  1144.  JM> When you escape from a option menu, it puts you back in the editor
  1145.  JM> rather than the menu.  This is bad design.
  1146.  
  1147. That's because options shouldn't be in menus, they should be in dialog boxes.
  1148.  Yes, the menu system in TP 6.0 isn't well designed.
  1149.  
  1150.  JM> With TP 5.x, I can hit F9 anywhere in the IDE to compile.  In 6.0,
  1151.  JM> you have to get out of a menu first.  This is very bad design.
  1152.  
  1153. There's a difference of philosophy here.  In a dialog box, the changes you
  1154. are making aren't applied until you hit Enter or Okay.  If you were allowed
  1155. to do a compile while in this state, you'd be compiling with the old options.
  1156.  Perhaps there should be a "Accept all options and compile" hot key, but people
  1157. mostly don't spend a lot of time flipping options, so it's probably not worth
  1158. adding.
  1159.  
  1160. --- Msg V3.2
  1161.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1162.  * Tossed by SFToss v1.00b on 92/03/17  11:00:28
  1163.  
  1164. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1165.  
  1166. Conference 4
  1167. Date       03-15-92 09:00:29
  1168. From       Dj Murdoch
  1169. To         John Gohde
  1170. Subject    Re: Ide Design
  1171.  
  1172.   JG> My
  1173.  JG> IDE currently has  a limit of about 250K or  about 7,500 lines or
  1174.  JG> apparently 4 times the 5.5 file  size limit. That may improved by
  1175.  JG> release time,  but I honestly  don't think a  programmer's editor
  1176.  JG> needs to deal with really big files. That feature would only take
  1177.  JG> up RAM.  
  1178.  
  1179. But sometimes programmers need to edit big files that aren't programs.  A
  1180. programmer's editor doesn't need to be optimized for these, but it's very
  1181. handy if it can handle them.
  1182.  
  1183. For example, if you were writing a nodelist compiler, and you wanted to stress
  1184. test it, you might put some weird errors into a full size version of it. 
  1185. It's nice to be able to do this in the same editor you're using for everything else.
  1186.  
  1187.  
  1188.  JG> The clipboard never made a whole lot of sense to me as it adds an
  1189.  JG> extra step.  In my IDE, with  F7/F8 you can move  blocks directly
  1190.  JG> from source window  to destination window or you  can implement a
  1191.  JG> clipboard approach by using the Delete Buffer (of 300 or whatever
  1192.  JG> lines).  8-)
  1193.  
  1194. That's a big improvement.  I hate the clipboard.
  1195.  
  1196.  
  1197.  
  1198. --- Msg V3.2
  1199.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1200.  * Tossed by SFToss v1.00b on 92/03/17  11:00:29
  1201.  
  1202. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1203.  
  1204. Conference 4
  1205. Date       03-15-92 09:11:58
  1206. From       Dj Murdoch
  1207. To         Richard Morris
  1208. Subject    Re: Ancestor VMT
  1209.  
  1210.   >     (P = Typeof (Self)) or Parent.DescendsFrom(P);
  1211.  
  1212.  RM> MMMM<grin>mmmm, you see what I mean!
  1213.  
  1214.  >>  If each Object in TP saved it's ancestor's VMT segment in it's
  1215.  >> virtual method table then I could query along the chain until I got
  1216.  >> to the desired object or a nil VMT segment indicating trhe chain
  1217.  >> ended with the root Object Type.  This would extend to the Turbo
  1218.  >> vision heirachy.
  1219.  
  1220.  > I see the benefits of the feature.  Have you written
  1221.  > Borland?
  1222.  
  1223. Thinking about this, I see a very big problem both with the code version above
  1224. and the modification to the VMT.  It would really interact badly with the
  1225. TP linker, as follows:
  1226.  
  1227.   Currently, the VMT is only linked in if there's a direct or indirect reference
  1228. to it.  TypeOf(Self) makes a direct reference to the VMT; calling a constructor
  1229. (without the type modifier prefix) makes an indirect reference to it.  There
  1230. aren't any other references that I can think of to the original VMT; all virtual
  1231. method calls, for instance, use the pointer in the object, not the fixed VMT
  1232. address.
  1233.  
  1234.   Same thing for code.  Code is only linked when you give a direct reference
  1235. (e.g. call a procedure or static method, or a virtual method with a type overrid
  1236. ) or an indirect reference.  Indirect references include using procedures
  1237. that make direct references, use another routine in the same .OBJ file, or
  1238. (and this is the point), make some reference to the VMT.
  1239.  
  1240. If you link a type's VMT, you get all the virtual methods, whether you need
  1241. them or not.
  1242.                                              So what's the point?  Well, think
  1243. about that DescendsFrom method or the VMT modification described below it.
  1244.  It makes a direct reference to its VMT.  It also makes a direct reference
  1245. to Parent.DescendsFrom, which makes a direct reference to the parent VMT,
  1246. and so on.  That means that *every* VMT and hence every virtual method for
  1247. any ancestor of any object you construct will be linked into your .EXE. 
  1248.  
  1249. The only way I can see around this problem is to improve the TP linker so
  1250. that it takes account of which VMT entries are needed and which aren't.
  1251.  
  1252. --- Msg V3.2
  1253.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1254.  * Tossed by SFToss v1.00b on 92/03/17  11:00:29
  1255.  
  1256. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1257.  
  1258. Conference 4
  1259. Date       03-16-92 21:29:05
  1260. From       Dj Murdoch
  1261. To         Trevor Carlsen
  1262. Subject    Re: Tp 6.0 Ide
  1263.  
  1264.   DW> I have to disagree with you on that one.  The IDE provides at least 
  1265.  DW> one necessary debugging feature - location of runtime errors in the 
  1266.  DW> code...
  1267.  
  1268.  TC> That is available in any good programming editor - not just the IDE.
  1269.  
  1270. Read what he wrote - he's talking run-time errors, not compile errors.  To
  1271. get those from other editors you generally have to recompile with the /F option,
  1272. and retype the address.
  1273.  
  1274.  
  1275. --- Msg V3.2
  1276.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1277.  * Tossed by SFToss v1.00b on 92/03/17  11:00:29
  1278.  
  1279. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1280.  
  1281. Conference 4
  1282. Date       03-16-92 21:36:20
  1283. From       Dj Murdoch
  1284. To         Hans Siemons
  1285. Subject    Re: TP 6.0 disassembler...
  1286.  
  1287.   GW>> 6.0 It's called TPU60.* (comes to about 120K) and "decompiles" TPU
  1288.  GW>> files, including all constants (internal or external), all
  1289.  GW>> procedures/functions, objects (untested as yet), optionally provides
  1290.  GW>> assembly code (ie. disassembles each procedure) and cross-references
  1291.  GW>> everything, and even includes the names of the *.OBJ files (if any)
  1292.  GW>> you linked in as external procedures!
  1293.  DM> Yes, I've seen that one, and it's really good.  If 
  1294.  HS> you want to patch a
  1295.  DM> .TPU file, that's the one to get.
  1296.  
  1297.  HS> Hmm, I want to get it! Do you know where I can freq this 
  1298.  HS> baby? On 14k4 if possible (I don't mind requesting 
  1299.  HS> oversees as long as it not on 2400bps ;-)).
  1300.  
  1301. I sent it out on the PDN Pascal file echo in October last year as TPU6.ZIP.
  1302.  It's probably available closer to you, but the only system I know of for
  1303. sure is 1:221/177.  That's 14.4 HST, but I've heard from Europeans that they
  1304. have trouble connecting, so watch out that you don't make a lot of wasted
  1305. phone calls.
  1306.  
  1307. --- Msg V3.2
  1308.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1309.  * Tossed by SFToss v1.00b on 92/03/17  11:00:29
  1310.  
  1311. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1312.  
  1313. Conference 4
  1314. Date       03-16-92 21:44:56
  1315. From       Dj Murdoch
  1316. To         Rob Kittredge
  1317. Subject    Re: C++ products
  1318.  
  1319.   RK> Terry,
  1320.  RK>   I seem to like TP's style better than C's, but I like 
  1321.  RK> the C++ (3.0) IDE and project management features.  After 
  1322.  RK> playing with C++'s project management, I can see that (to 
  1323.  RK> me) it is far superior than specifying the usual 10-15 
  1324.  RK> USES list in EVERY unit that I write!  Most of which are OP stuff :-). 
  1325.  
  1326.  
  1327. I though in C++ you generally had to include header files, so you'd end up
  1328. with just as many includes as you now have uses.  But even if I'm wrong, it
  1329. doesn't sound like a great style.  Units should be focussed - they should
  1330. have a clear purpose.  For me, this generally means that they don't get 10
  1331. or 15 units in the Uses list - more like 5 or 6.  The main program (or the
  1332. unit that dispatches commands to the other units) often ends up with more.
  1333.  
  1334.  
  1335. --- Msg V3.2
  1336.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1337.  * Tossed by SFToss v1.00b on 92/03/17  11:00:29
  1338.  
  1339. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1340.  
  1341. Conference 4
  1342. Date       03-16-92 21:49:22
  1343. From       Dj Murdoch
  1344. To         Andrew Knobloch
  1345. Subject    Re: Data Compression Techniques ********
  1346.  
  1347.   AK>   I program mainly in Turbo PASCAL (with some assembly 
  1348.  AK> language on the side)... Anyhow, I'd really like to know 
  1349.  AK> how to compress files and data structures from within a 
  1350.  AK> PASCAL program.  One algorithm that I do have is called 
  1351.  AK> Huffman Encoding.  Not only is Huffman Encoding slow but 
  1352.  AK> it only squishes TEXT files by a maximum of 20 or 30 
  1353.  AK> percent.  Hardly worth any squishing at all.  Anywayz, if 
  1354.  AK> anyone knows of a good compression algorithm that is not 
  1355.  AK> necessarily fast, let me know.  
  1356.  
  1357. Look for TPLZW.  It was written by Wilbert van Leijen, and does good Lempel-
  1358. Ziv-Welch compression pretty quickly.  It won't compress a small file, but
  1359. on a long enough text file (e.g. 24K) you get 50 or 60 percent compression.
  1360.  
  1361. If you can't find it, hold on for a few days (weeks?).  I'm going to release
  1362.  a unit of stream utilities that makes use of Wilbert's code to compress any
  1363. stream.
  1364.  
  1365. --- Msg V3.2
  1366.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1367.  * Tossed by SFToss v1.00b on 92/03/17  11:00:29
  1368.  
  1369. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1370.  
  1371. Conference 4
  1372. Date       03-16-92 21:57:22
  1373. From       Dj Murdoch
  1374. To         Jud Mccranie
  1375. Subject    Exponentiation (was: Are you...)
  1376.  
  1377.   JM> Don't hold your breath.  I requested the exponential operator back
  1378.  JM> in 2.0 or 3.0.  I even requested in the USCD Apple Pascal days.  They
  1379.  JM> called me on the phone and told me how to do it (I knew that, of
  1380.  JM> course).  They can write a better one than I can.
  1381.  
  1382. Something that's changed since then is the publication and acceptance of the
  1383. new Extended Pascal standard.  It has an exponentiation operator ("**", like
  1384. Fortran).  I don't know if Borland has any intention of paying attention to
  1385. the new standard (any more than they paid attention to the old one :-), but
  1386. other vendors on other machines (e.g. VAX Pascal) are.
  1387.  
  1388. --- Msg V3.2
  1389.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1390.  * Tossed by SFToss v1.00b on 92/03/17  11:00:29
  1391.  
  1392. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1393.  
  1394. Conference 4
  1395. Date       03-16-92 22:01:51
  1396. From       Dj Murdoch
  1397. To         Ivan Samuelson
  1398. Subject    Re: C+ vs Turbo Pascal
  1399.  
  1400.   IS> Just C in general is an excellent language. I've got both 
  1401.  IS> Turbo Pascal and C++. but if you want a language that 
  1402.  IS> allows you flexibility in manipulating right down to the 
  1403.  IS> bits, C is the way to go. Pascal is VERY restrictive in 
  1404.  IS> what you can and cannot manipulate.
  1405.  
  1406. Standard Pascal is very restrictive, but I can't think of anything in C that's
  1407. impossible in TP 6.  Could you give some examples?  I suspect you just aren't
  1408. familiar enough with it.
  1409.  
  1410. There are definitely cases where the C construct will be more efficient &
  1411. probably shorter to code, but I don't think there's anything that just can't
  1412. be done in TP.  (There are also cases where the TP code will be more efficient
  1413. and/or shorter.  For example, compile the TurboCalc sample program in both
  1414. C & TP, and I think you'll find the TP version is smaller.)
  1415.  
  1416.  IS> Pascal was created to be a learning language. It was and 
  1417.  IS> is used to teach programming techniques in 
  1418.  IS> structured/modular programming. Hence, it doesn't allow 
  1419.  IS> you to manipulate on the bit-wise level of computing. 
  1420.  IS> Also, Pascal will do range checking on arrays. If you step 
  1421.  IS> out of bounds, Pascal will catch it. C WON'T do that. You 
  1422.  IS> have to do it yourself. That's where some will see the 
  1423.  IS> downfall of C while others, like myself, say it's great. C 
  1424.  IS> gives YOU the responsibility to check everything, which 
  1425.  IS> allows for greater flexibility in programming.
  1426.  
  1427. Now I'm sure it's because of unfamiliarity.  In TP, the $R option controls
  1428. whether range checking takes place.  Turn it off if you don't want it. 
  1429.  
  1430. --- Msg V3.2
  1431.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1432.  * Tossed by SFToss v1.00b on 92/03/17  11:00:30
  1433.  
  1434. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1435.  
  1436. Conference 4
  1437. Date       03-17-92 03:33:28
  1438. From       Trevor Carlsen
  1439. To         Ivan Samuelson
  1440. Subject    C+ vs Turbo Pascal
  1441.  
  1442.  
  1443.  
  1444.  IS> Just C in general is an excellent language. I've got both Turbo Pascal 
  1445.  
  1446.  IS> and C++. but if you want a language that allows you flexibility in 
  1447.  IS> manipulating right down to the bits, C is the way to go. Pascal is 
  1448.  IS> VERY restrictive in what you can and cannot manipulate.
  1449.  
  1450.  IS> Pascal was created to be a learning language. It was and is used to 
  1451.  IS> teach programming techniques in structured/modular programming. Hence, 
  1452.  
  1453.  IS> it doesn't allow you to manipulate on the bit-wise level of computing. 
  1454.  
  1455.  IS> Also, Pascal will do range checking on arrays. If you step out of 
  1456.  IS> bounds, Pascal will catch it. C WON'T do that. You have to do it 
  1457.  IS> yourself. That's where some will see the downfall of C while others, 
  1458.  
  1459.  IS> like myself, say it's great. C gives YOU the responsibility to check 
  1460.  
  1461.  IS> everything, which allows for greater flexibility in programming.
  1462.  
  1463. When comparing languages it is only fair to do so if you know what you are
  1464. talking about. The above comments that you make about Pascal are true if you
  1465. are referring to standard Pascal.  However your subject line AND the first
  1466. quoted line above would indicate that you are referring to, or at the very
  1467. least including, Turbo Pascal in your assertations.  If so then your statement
  1468. is wrong on several points.
  1469.  
  1470. TP *can* easily manipulate bits. 
  1471. (Operators used for this are shl, shr, and, or, xor, not)
  1472.  
  1473. TP *can* disregard range checking of array bounds.
  1474. (Read up on the R+/- compiler directive)
  1475.  
  1476. TeeCee
  1477.  
  1478.  
  1479.  
  1480.  
  1481. --- TC-ED   v2.01  
  1482.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1483.  * Tossed by SFToss v1.00b on 92/03/17  20:24:20
  1484.  
  1485. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1486.  
  1487. Conference 4
  1488. Date       03-17-92 04:11:45
  1489. From       Trevor Carlsen
  1490. To         Jan Hoolwerf
  1491. Subject    Pascal <==> C string translation
  1492.  
  1493.  
  1494.  
  1495.  JH> Probably not a new question but i would appreciate to have some 
  1496.  JH> routines to translate C strings (null terminated) to Pascal strings. 
  1497.  
  1498.  JH> And back to C strings. :-)
  1499.  
  1500. C strings are just arrays of characters that are terminated by a nul character.
  1501. TP strings are arrays of characters that use the zero element of the array
  1502. to indicate the length of the string.  Naturally this limits TP strings to
  1503. 255 characters.
  1504.  
  1505.  function Asc2Str(var s; max: byte): string;
  1506.    { Converts an ASCIIZ string s to a Turbo Pascal string }
  1507.    { with a maximum length of max.                      }
  1508.    var starray  : array[1..255] of char absolute s;
  1509.        len      : integer;
  1510.    begin
  1511.      len        := pos(#0,starray)-1;                       { Get the length }
  1512.  
  1513.      if (len > max) or (len < 0) then               { length exceeds maximum }
  1514.  
  1515.        len      := max;                                  { so set to maximum }
  1516.  
  1517.      Asc2Str    := starray;
  1518.      Asc2Str[0] := chr(len);                                    { Set length }
  1519.  
  1520.    end;  { Asc2Str }
  1521.  
  1522.  type 
  1523.    CStr = array[0..255] of char;
  1524.  
  1525.  procedure TPStr2Asc(var s: string; var a: CStr);
  1526.    { Converts a TP string s to a nul terminated C string a }
  1527.    begin
  1528.      a[length(s)] := #0;
  1529.      move(s[1],a[0],length(s));
  1530.    end;  { TPStr2Asc }
  1531.  
  1532. TeeCee
  1533.   
  1534.  
  1535.  
  1536. --- TC-ED   v2.01  
  1537.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1538.  * Tossed by SFToss v1.00b on 92/03/17  20:24:20
  1539.  
  1540. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1541.  
  1542. Conference 4
  1543. Date       03-17-92 06:13:58
  1544. From       Trevor Carlsen
  1545. To         Gerald Gutierrez
  1546. Subject    Printer Status
  1547.  
  1548.  
  1549.  
  1550.  > Let's Stamp Out Assembler on Pascal! ;-) Gee, I bet the assembler
  1551.  > solution  will save  me .000000043  seconds execution  time in my
  1552.  > program.  What a lost.
  1553.  
  1554.  GG> And just a COUPLE bytes of exe data.. :) Pascal is fine for small 
  1555.  GG> applications that don't take much time -- but once it gets up to the 
  1556.  
  1557.  GG> 50+ line procedures, ASM helps tremendously in both execution time and 
  1558.  
  1559.  GG> size. IE: Last graphics scroll routine worked on; approximately 150 
  1560.  GG> lines Pascal code, about 170 lines ASM code, execution times 25+ times 
  1561.  
  1562.  GG> faster.
  1563.  
  1564. I must agree with John Gohde on this.  There is no need to resort to BASM
  1565. or assembler code in TP programs unless there is justifiable reason for it.
  1566.  
  1567. I define "justifiable reason" as being one of the following -
  1568.  
  1569.   * The code is speed sensitive to the point where the use of assembler
  1570.     is essential for that speed sensitive routine.
  1571.   * Where its use will make a noticeable difference to the end user's
  1572.     perception of the speed the program runs at.
  1573.   * Where TP is unable to perform the defined task.
  1574.   * When size of exe code is critical and use of BASM code reduces the 
  1575.     code size significantly.
  1576.   * When I do not wish to use a particular unit (such as DOS) and BASM
  1577.     allows me to easily create a replacement procedure or function from
  1578.     that unit.
  1579.   * When using assembler is the easiest method to use.
  1580.  
  1581. Too often we see code posted here that, using the above criteria, appears
  1582. to use BASM unnecessarily.  When I see such code I tend to think the poster
  1583. is on an ego trip. :-)
  1584.  
  1585. TeeCee
  1586.  
  1587. --- TC-ED   v2.01  
  1588.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1589.  * Tossed by SFToss v1.00b on 92/03/17  20:24:20
  1590.  
  1591. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1592.  
  1593. Conference 4
  1594. Date       03-17-92 06:44:09
  1595. From       Trevor Carlsen
  1596. To         Andreas Holtmann
  1597. Subject    Text Files
  1598.  
  1599.  
  1600.  
  1601.  AH> const lines = 1024;
  1602.  
  1603.  AH> var myfile : array [1..lines] of string;
  1604.  AH>     file_handle : text;
  1605.  AH>     name = string;
  1606.  AH>     line : integer;
  1607.  
  1608. This would not even compile, let alone run.  To enable compilation to be complet
  1609. d the value of lines would have to be reduced to 253 or less.  (No structure
  1610. can exceed just under 64K in size and the total of global variables is limited
  1611. to just under 64K.)
  1612.  
  1613. TeeCee
  1614.  
  1615.  
  1616.  
  1617. --- TC-ED   v2.01  
  1618.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1619.  * Tossed by SFToss v1.00b on 92/03/17  20:24:20
  1620.  
  1621. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1622.  
  1623. Conference 4
  1624. Date       03-17-92 07:01:25
  1625. From       Trevor Carlsen
  1626. To         Mike Copeland
  1627. Subject    BLOCKWRITE QUESTION.
  1628.  
  1629.  
  1630.  
  1631.  MC> ... (The EOF is written only at Close time, only at 
  1632.  MC> the end of the file.)
  1633.  
  1634. TP does not add an end-of-file character unless the programmer specifically
  1635. adds it. This is explained in detail in the manual under Read as regards reading
  1636. of text files. It would be easy to assume that TP adds an eof character to
  1637. files if using the read procedure.  Examination of files created with TP by
  1638. an utility such as PCTools will show no eof character present. I do believe
  1639. however that some reference to this should be included in the section for
  1640. the close procedure.
  1641.  
  1642. TeeCee
  1643.  
  1644. --- TC-ED   v2.01  
  1645.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1646.  * Tossed by SFToss v1.00b on 92/03/17  20:24:20
  1647.  
  1648. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1649.  
  1650. Conference 4
  1651. Date       03-17-92 16:52:27
  1652. From       Trevor Carlsen
  1653. To         Greg Williams
  1654. Subject    Re: Pascal Vs. C
  1655.  
  1656.  
  1657.  
  1658.  GW> Hmm..... some compilers don't require an explicit EXPORT command (to 
  1659.  
  1660.  GW> declare their interfaced/public routines and variables.  One such 
  1661.  GW> compiler is the JPI Modula-2...  I don't use EXPORT usually, but it 
  1662.  GW> SHOULD be supported (as it's part of the language spec (I think?!))... 
  1663.  
  1664.  
  1665. This message bears no relationship to your subject line and is not related
  1666. to the subject matter of this conference.  Please take any further discussion
  1667. to netmail.
  1668.  
  1669. Trevor Carlsen
  1670. Moderator.
  1671.  
  1672. --- TC-ED   v2.01  
  1673.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1674.  * Tossed by SFToss v1.00b on 92/03/17  20:24:21
  1675.  
  1676. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1677.  
  1678. Conference 4
  1679. Date       03-17-92 08:06:53
  1680. From       Dj Murdoch
  1681. To         Kenneth Otto
  1682. Subject    Re: Borland pascal 6.1?
  1683.  
  1684.   KO> So, is Turbo Pascal 6.1 rumored to be on the way?
  1685.  
  1686. I haven't heard anything about TP 6.1, but Borland has said on Compuserve
  1687. that they plan to release a high end version of TP called "Borland Pascal"
  1688. sometime this year.  It's supposed to support (include?) a DOS extender, so
  1689. you can write protected mode programs without Windows; if it's like Borland
  1690. C++, it'll also support Windows.  
  1691.  
  1692. I've also seen somewhere that Borland plans eventually to produce an OS/2
  1693. version of TP, but probably not this year.
  1694.  
  1695. --- Msg V3.2
  1696.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1697.  * Tossed by SFToss v1.00b on 92/03/18  11:26:05
  1698.  
  1699. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1700.  
  1701. Conference 4
  1702. Date       03-17-92 08:10:37
  1703. From       Dj Murdoch
  1704. To         Mike Copeland
  1705. Subject    Re: Pascal, The Language
  1706.  
  1707.   JM>Do assemblers have user-defined data types?
  1708.  
  1709.  MC>    Certainly! When you consider how Pascal implements 
  1710.  MC> user-defined data types (it maps the hardware-defined data 
  1711.  MC> to its data types), Assembler can do the same, and more...
  1712.  
  1713. More like "the same, and less".  Most assemblers don't do type checking beyond
  1714. the size of the argument; that's a lot less useful than Pascal's strong type
  1715. checking.
  1716.  
  1717. --- Msg V3.2
  1718.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1719.  * Tossed by SFToss v1.00b on 92/03/18  11:26:05
  1720.  
  1721. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1722.  
  1723. Conference 4
  1724. Date       03-17-92 08:14:02
  1725. From       Dj Murdoch
  1726. To         Steve Gabrilowitz
  1727. Subject    Re: Delay patch
  1728.  
  1729.   SG> OK, but I still think a better solution is to write your 
  1730.  SG> own delay routine that is not dependant on the speed of the machine.
  1731.  
  1732. I think the point is that that is quite difficult.  If you want it to run
  1733. accurately on anything from a 4.77 MHz PC to a 1000 Mhz 786, you'll need to
  1734. do some fancy programming.
  1735.  
  1736. --- Msg V3.2
  1737.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1738.  * Tossed by SFToss v1.00b on 92/03/18  11:26:06
  1739.  
  1740. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1741.  
  1742. Conference 4
  1743. Date       03-17-92 08:16:14
  1744. From       Dj Murdoch
  1745. To         J J Marquez
  1746. Subject    Re: Are you listening... ?
  1747.  
  1748.   JJ>    Wanna know what my greatest fear is ? That C++ will add 
  1749.  JJ> it in first, causing me to have to learn C.... AAAaaaaaaiiiieeeeee! 
  1750.  
  1751. I'm pretty sure that most numerical libraries for C++ add it in.  There are
  1752. some advantages to being able to redefine operators.
  1753.  
  1754. --- Msg V3.2
  1755.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  1756.  * Tossed by SFToss v1.00b on 92/03/18  11:26:06
  1757.  
  1758. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1759.  
  1760. Conference 4
  1761. Date       03-18-92 06:38:44
  1762. From       Trevor Carlsen
  1763. To         Dale Frakes
  1764. Subject    Variable # parameters
  1765.  
  1766.  
  1767.  
  1768.  DF> Does anyone out there know how to write a pascal (TP 6.0) function or 
  1769.  
  1770.  DF> procedure that accepts a variable number of parameters.  I assume this 
  1771.  
  1772.  DF> is possible, since Write, Writeln, Read, Readln, Concat, etc all 
  1773.  DF> accept variable number of parameters, and they are written in Pascal.  
  1774.  
  1775.  DF> Has someone who has seen the source for the Run Time Libraries know 
  1776.  DF> how this is done?  Again, I would assume that if someone can compile 
  1777.  
  1778.  DF> the RTL, it can be done within the Pascal environment.
  1779.  
  1780. Strictly speaking it cannot be done.  The procedures you refer to that *appear*
  1781. to do that are actually changed by the compiler to effectively be *several*
  1782. procedures in the actual exe file.
  1783.  
  1784. You could however create a procedure that gives the effect of a variable number
  1785. of parameters by passing a single parameter which is a linked list.  I've
  1786. never found that it is necessary to do this in the time I have been programming.
  1787.  
  1788. If you want to emulate the write/writeln/read/readln procedures at some time,
  1789. it is easy to set up a TFDD (text file device driver) to do so.  The next
  1790. issue of PNL (#11) may have an article explaining this very useful technique.
  1791.  
  1792. TeeCee
  1793.  
  1794. --- TC-ED   v2.01  
  1795.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1796.  * Tossed by SFToss v1.00b on 92/03/18  18:50:18
  1797.  
  1798. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1799.  
  1800. Conference 4
  1801. Date       03-18-92 13:35:36
  1802. From       Trevor Carlsen
  1803. To         Frank Livaudais
  1804. Subject    Text Files (1 of 3)
  1805.  
  1806.  
  1807.  
  1808.  FL> I want to read in text files bt make them binary so that you cant 
  1809.  FL> 'type' them from dos.
  1810.  
  1811. I think that the fastest and easiest way of doing this would be to use some
  1812. form of very simple encryption.  Here is a program to encrypt or decrypt a
  1813. file - any file - using a simple password as your key and a key file that
  1814. you have on your system that is not subject to ever being altered. This approach
  1815. s being totally secure as it is almost a "one time pad" method.
  1816.  
  1817. It is tested as far as compilation is concerned and also briefly for valid
  1818. execution.  It appears to work Ok.
  1819.  
  1820. {$A+,B-,D-,E+,F-,G+,I+,L-,N-,O-,R-,S-,V-,X+}
  1821. {$M 4048,0,131040}
  1822. program encrypt;
  1823.  
  1824. { Author Trevor J Carlsen - released into the public domain 1992         }
  1825. {        PO Box 568                                                      }
  1826. {        Port Hedland                                                    }
  1827. {        Western Australia 6721                                          }
  1828. {        Voice +61 91 73 2026  Data +61 91 73  2569                      }
  1829. {        FidoNet 3:690/644                                               }
  1830.  
  1831. { Syntax: encrypt /p=Password /k=Keyfile /f=File                         }
  1832. { Example -                                                              }
  1833. {         encrypt /p=billbloggs /k=c:\command.com /f=p:\prog\anyfile.pas }
  1834.  
  1835. {         Password can be any alpha-numeric sequence of AT LEAST four    }
  1836. {         characters.                                                    }
  1837.  
  1838. {         Keyfile is the full path of any file on the system that this   }
  1839. {         program runs on.  This file, preferably a large one, must not  }
  1840. {         be subject to changes.  This is critical as it is used as a    }
  1841. {         pseudo "one time pad" style key and the slightest change will  }
  1842. {         render decryption invalid.                                     }
  1843.  
  1844. {         File is the full path of the file to be encrypted or decrypted.}
  1845.  
  1846. { Notes:  Running Encrypt a second time with exactly the same parameters }
  1847. {         decrypts an encrypted file.  For total security the keyfile    }
  1848. {         can be stored separately on a floppy.  Without this keyfile or }
  1849. {         knowledge of its contents it is IMPOSSIBLE to decrypt the      }
  1850. {         encrypted file.                                                }
  1851.  
  1852. {         Parameters are case insensitive and may be in any order and    }
  1853. {         may not contain any dos separator characters.                  }
  1854.  
  1855. const
  1856.   BufferSize   = 65520;
  1857.   Renamed      : boolean = false;
  1858.  
  1859. type
  1860.   buffer_      = array[0..BufferSize - 1] of byte;
  1861.   buffptr      = ^buffer_;
  1862.   str80        = string[80];
  1863.  
  1864. var
  1865.   OldExitProc  : pointer;
  1866.   KeyFile,
  1867.   OldFile,
  1868.   NewFile      : file;
  1869.   KeyBuffer,
  1870.   Buffer       : buffptr;
  1871.   KeyFileSize,
  1872.   EncFileSize  : longint;
  1873.   Password,
  1874.   KFName,
  1875.   FFName       : str80;
  1876.  
  1877. continued next message.
  1878.  
  1879. --- TC-ED   v2.01  
  1880.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1881.  * Tossed by SFToss v1.00b on 92/03/18  18:50:19
  1882.  
  1883. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1884.  
  1885. Conference 4
  1886. Date       03-18-92 13:38:59
  1887. From       Trevor Carlsen
  1888. To         Frank Livaudais
  1889. Subject    Text Files (2 of 3)
  1890.  
  1891.  
  1892.  
  1893. ... continued from previous message
  1894.  
  1895. procedure Hash(p : pointer; numb : byte; var result: longint);
  1896.   { When originally called numb must be equal to sizeof    }
  1897.   { whatever p is pointing at.  If that is a string numb   }
  1898.   { should be equal to length(the_string) and p should be  }        
  1899.   { ptr(seg(the_string),ofs(the_string)+1)                 }
  1900.   var
  1901.     temp,
  1902.     w    : longint;
  1903.     x    : byte;
  1904.  
  1905.   begin
  1906.     temp := longint(p^);  RandSeed := temp;
  1907.     for x := 0 to (numb - 4) do begin
  1908.       w := random(maxint) * random(maxint) * random(maxint);
  1909.       temp := ((temp shr random(16)) shl random(16)) +
  1910.                 w + MemL[seg(p^):ofs(p^)+x];
  1911.     end;
  1912.     result := result xor temp;
  1913.   end;  { Hash }
  1914.  
  1915. procedure NewExitProc; far;
  1916.   { Does the "housekeeping" necessary on program termination }
  1917.   var code : integer;
  1918.   begin
  1919.     ExitProc := OldExitProc;  { Reset exit procedure pointer to original }
  1920.     case ExitCode of
  1921.     0: writeln('Successfully encrypted or decrypted ',FFName);
  1922.     1: begin
  1923.          writeln('This program requires 3 parameters -');
  1924.          writeln('  /pPassword');
  1925.          writeln('  /kKeyFile (full path and name)');
  1926.          write  ('  /fFile (The full path and name of the file');
  1927.          writeln(' to be processed)');
  1928.          writeln;
  1929.          write  ('These parameters can be in any order, are case,');
  1930.          writeln(' insensitive, and may not contain any spaces.');
  1931.        end;
  1932.     2: writeln('Could not find key file');
  1933.     3: writeln('Could not rename and/or open original file');
  1934.     4: writeln('Could not create encrypted file');
  1935.     5: writeln('I/O error during processing - could not complete');
  1936.     6: writeln('Insufficient memory available');
  1937.     7: begin
  1938.          writeln('Key  file is too small - aborted');
  1939.          writeln;
  1940.          writeln(' Key File must be at least as large as the buffer size ');
  1941.          write  (' or the size of the file to be encrypted, whatever is the');
  1942.          writeln(' smaller.');
  1943.        end;
  1944.     8: writeln('Password must consist of at least 4 characters');
  1945.     else { any other error }
  1946.       writeln('Aborted with error ',ExitCode);
  1947.     end; { case }
  1948.     if Renamed and (ExitCode <> 0) then
  1949.       writeln(#7'WARNING: Original file''s name is now TEMP.$$$');
  1950.     {$I-}
  1951.     close(KeyFile); Code := IOResult;
  1952.     close(NewFile); Code := IOResult;
  1953.     close(OldFile); Code := IOResult;
  1954.     if ExitCode = 0 then
  1955.       Erase(OldFile); Code := IOResult;
  1956.     {$I+}
  1957.   end; { NewExitProc }
  1958.  
  1959.  
  1960. function Str2UpCase(var S: string): string;
  1961.   { Converts a string S to upper case.  Valid for English. }
  1962.   var
  1963.     x : byte;
  1964.   begin
  1965.     Str2UpCase[0] := S[0];
  1966.     for x := 1 to length(S) do
  1967.       Str2UpCase[x] := UpCase(S[x]);
  1968.   end; { Str2UpCase }
  1969.  
  1970. continued in next message...
  1971.  
  1972.  
  1973.  
  1974.  
  1975.  
  1976. --- TC-ED   v2.01  
  1977.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  1978.  * Tossed by SFToss v1.00b on 92/03/18  18:50:19
  1979.  
  1980. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  1981.  
  1982. Conference 4
  1983. Date       03-18-92 13:42:39
  1984. From       Trevor Carlsen
  1985. To         Frank Livaudais
  1986. Subject    Text Files (3 of 3)
  1987.  
  1988.  
  1989.  
  1990. ... continued from previous message
  1991.  
  1992. procedure Initialise;
  1993.   var
  1994.     CommandLine : string;
  1995.     FPos,FLen,
  1996.     KPos,KLen,
  1997.     PPos,PLen   : byte;
  1998.  
  1999.   procedure  AllocateMemory(var p: buffptr; size: longint);
  2000.     begin
  2001.       if size < BufferSize then begin
  2002.         if MaxAvail < size then halt(6);
  2003.         GetMem(p,size);
  2004.       end
  2005.       else begin
  2006.         if MaxAvail < BufferSize then halt(6);
  2007.         new(p);
  2008.       end;
  2009.     end; { AllocateMemory }
  2010.  
  2011.   begin
  2012.     FillChar(OldExitProc,404,0);       { Initialise all global variables }
  2013.     FillChar(Password,243,32);
  2014.     ExitProc    := @NewExitProc;             { Set up new exit procedure }
  2015.     if ParamCount <> 3 then halt(1);
  2016.     CommandLine := string(ptr(PrefixSeg,$80)^)+' '; { Add trailing space }
  2017.     CommandLine := Str2UpCase(CommandLine);      { Convert to upper case }
  2018.     PPos        := pos('/P=',CommandLine);     { Find password parameter }
  2019.     KPos        := pos('/K=',CommandLine);      { Find keyfile parameter }
  2020.     FPos        := pos('/F=',CommandLine); { Find filename for encryption}
  2021.     if (PPos = 0) or (KPos = 0) or (FPos = 0) then    { Parameters wrong }
  2022.       Halt(1);
  2023.     FFName      := copy(CommandLine,FPos+3,80);
  2024.     FFName[0]   := chr(pos(' ',FFName)-1);       { Correct string length }
  2025.     KFName      := copy(CommandLine,KPos+3,80);
  2026.     KFName[0]   := chr(pos(' ',KFName)-1);
  2027.     Password    := copy(CommandLine,PPos+3,80);
  2028.     Password[0] := chr(pos(' ',Password)-1);
  2029.     if length(Password) < 4 then halt(8);
  2030.     { Create a random seed value based on the password }
  2031.     Hash(ptr(seg(Password),ofs(Password)+1),length(Password),RandSeed);
  2032.     assign(OldFile,FFName);
  2033.     {$I-}
  2034.     rename(OldFile,'TEMP.$$$');        { Rename the file to be encrypted }
  2035.     if IOResult <> 0 then halt(3) else renamed := true;
  2036.     assign(OldFile,'TEMP.$$$');
  2037.     reset(OldFile,1);
  2038.     if IOResult <> 0 then halt(3);
  2039.     assign(NewFile,FFName);
  2040.     rewrite(NewFile,1);
  2041.     if IOResult <> 0 then halt(4);
  2042.     assign(KeyFile,KFName);
  2043.     reset(KeyFile,1);
  2044.     if IOResult <> 0 then halt(2);
  2045.     EncFileSize := FileSize(OldFile);
  2046.     KeyFileSize := FileSize(KeyFile);
  2047.     if KeyFileSize > EncFileSize then KeyFileSize := EncFileSize;
  2048.     if IOResult <> 0 then halt(5);
  2049.     {$I+}
  2050.     if (KeyFileSize < BufferSize) and (KeyFileSize < EncFileSize) then   
  2051.     halt(7);
  2052.     AllocateMemory(buffer,EncFileSize);
  2053.     AllocateMemory(KeyBuffer,KeyFileSize);
  2054.   end; { Initialise }
  2055.  
  2056. procedure Main;
  2057.   var
  2058.     BytesRead : word;
  2059.     finished  : boolean;
  2060.  
  2061.   procedure CodeBuffer(number: word);
  2062.     { This is the actual encryption/decryption engine }
  2063.     var x : word;
  2064.     begin
  2065.       for x := 0 to number - 1 do
  2066.         buffer^[x] := buffer^[x] xor KeyBuffer^[x] xor Random(256);
  2067.     end; { CodeBuffer }
  2068.  
  2069.   begin
  2070.     {$I-}
  2071.     finished := false;
  2072.     repeat
  2073.       BlockRead(OldFile,buffer^,BufferSize,BytesRead);
  2074.       if (FilePos(KeyFile) + BytesRead) > KeyFileSize then
  2075.         seek(KeyFile,0);
  2076.       BlockRead(KeyFile,KeyBuffer^,BytesRead,BytesRead);
  2077.       CodeBuffer(BytesRead);
  2078.       finished := BytesRead < BufferSize;
  2079.       BlockWrite(NewFile,buffer^,BytesRead);
  2080.       if IOResult <> then halt(5);
  2081.     until finished;
  2082.     {$I+}
  2083.   end;  { Main }
  2084.  
  2085. begin
  2086.   Initialise;
  2087.   Main;
  2088. end.
  2089.  
  2090. TeeCee
  2091.  
  2092.  
  2093. --- TC-ED   v2.01  
  2094.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2095.  * Tossed by SFToss v1.00b on 92/03/18  18:50:19
  2096.  
  2097. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2098.  
  2099. Conference 4
  2100. Date       03-15-92 23:34:00
  2101. From       Terry Hughes
  2102. To         Joshua Kersey @ 930/22
  2103. Subject    ExecSwap
  2104.  
  2105.  
  2106. JK@9>I need help using ExecSwap, can anyone help me out? This
  2107. JK@9>little source does work, it executes it, but ARJ has no
  2108. JK@9>memory to work with at all, what's catching my shirttail
  2109. JK@9>here?
  2110.  
  2111. JK@9>In the ExecWSwp DOcs it says to use FreePtr^, but in TP,
  2112. JK@9>it's an "Unknown Identifier" and haven't stooped to buy
  2113. JK@P>TPRO yet...
  2114.  
  2115. FreePtr has nothing to do with TPRO. FreePtr is a system
  2116. variable used in the heap managment in versions 4 through 5.5 of
  2117. Turbo Pascal.
  2118.  
  2119. The EXECSWAP documentation explains three possible purposes for
  2120. LastToSave: 1) save no heap, 2) save all heap but free list and
  2121. 3) save all heap and free list. The third condition is the one
  2122. that requires the expression you were trying to use:
  2123. Ptr(Seg(FreePtr^)+$1000, 0). Under Turbo Pascal 6.0, which you
  2124. apparently are using, this expression is no longer necessary
  2125. since the free list is stored within the heap itself. So, case 2
  2126. is no longer applicable and case 3 becomes simply "HeapPtr".
  2127.  
  2128. In case that wasn't clear, just pass HeapPtr for LastToSave and
  2129. all will be well:
  2130.  
  2131.  if InitExecSwap(HeapPtr, 'EXECDEMO.$$$') then
  2132.    ...
  2133.  
  2134. -Terry
  2135.  
  2136.  * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  2137.  
  2138. --- Maximus 2.01wb
  2139.  * Origin: The Programmers Playhouse (1:128/60)
  2140.  * Tossed by SFToss v1.00b on 92/03/19  04:34:20
  2141.  
  2142. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2143.  
  2144. Conference 4
  2145. Date       03-17-92 15:46:02
  2146. From       Terry Hughes
  2147. To         Rob Kittredge
  2148. Subject    C++ products
  2149.  
  2150.  
  2151. RK> What was it that convinced you that TP was "better"
  2152. RK> than C++ in particular?
  2153.  
  2154. Just about everything. <g>
  2155.  
  2156. I can't compare the environments since I don't use either IDE.
  2157.  
  2158. To the languages themselves, TP is a much leaner/cleaner
  2159. language than C++. Bucking the trend here, I hope Borland keeps
  2160. TP simple and avoids the temptation to add all the myriad
  2161. features (gee gaws?) of C++ to TP. To me, TP's simplicity is
  2162. what makes it such a pleasure to work with and what can make a
  2163. TP programmer more productive than a C++ programmer.
  2164.  
  2165. Beyond that, the biggest issues were compilation capacity,
  2166. compilation speed, linking speed and ease of smart linking (in
  2167. C++, smart linking requires putting every smart-linkable
  2168. procedure in its own OBJ file). TP wins hands down in all of
  2169. those categories (although BC++ 3.0 caught up in compilation
  2170. capacity).
  2171.  
  2172. RK>  P.S. did you happen to take a look at my mods to OPRO for
  2173. RK>TP's MAKEHELP to support those "+1" constants?
  2174.  
  2175. We decided not to merge those changes into the production
  2176. MAKEHELP since it's not a request we've ever heard before.
  2177. However, we've kept your version of MAKEHELP around should the
  2178. need ever arise. Thanks for sending it.
  2179.  
  2180. -Terry
  2181.  
  2182.  * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  2183.  
  2184. --- Maximus 2.01wb
  2185.  * Origin: The Programmers Playhouse (1:128/60)
  2186.  * Tossed by SFToss v1.00b on 92/03/19  04:34:20
  2187.  
  2188. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2189.  
  2190. Conference 4
  2191. Date       03-17-92 15:47:04
  2192. From       Terry Hughes
  2193. To         Joshua Kersey @ 930/22
  2194. Subject    Re: Execute With Swap
  2195.  
  2196.  
  2197. JK@9>No, it wasn't posted, but the code's kinda long, I'll post
  2198. JK@9>it, if it's agreeable to Terry Hughes, it's part ASM and
  2199. JK@9>part Pascal..
  2200.  
  2201. It's OK by me (since it's PD code) but instead why don't I just
  2202. mention our BBS number here (719-260-9726). That way, Kevin can
  2203. come get it if he wants it and we'll avoid generating the
  2204. lengthy messages that the code would require.
  2205.  
  2206. -Terry
  2207.  
  2208.  
  2209.  * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  2210.  
  2211. --- Maximus 2.01wb
  2212.  * Origin: The Programmers Playhouse (1:128/60)
  2213.  * Tossed by SFToss v1.00b on 92/03/19  04:34:21
  2214.  
  2215. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2216.  
  2217. Conference 4
  2218. Date       03-18-92 08:39:06
  2219. From       Terry Hughes
  2220. To         Jud Mccranie
  2221. Subject    B-tree filer
  2222.  
  2223.  
  2224. JM>First, a slight misprint in the BTree manual, page 64, row 12,
  2225. JM>"NextKey" should be "BTNextKey".
  2226.  
  2227. Thanks. We'll fix that in the next printing.
  2228.  
  2229. JM>up for editing.  Then if I press pageDown (for next record), I use
  2230. JM>the NextPrev proc, but the first (only) time I do that it always calls
  2231. JM>up the very first record with the matching key, which is not generally
  2232. JM>the previous record.
  2233.  
  2234. BTNextKey has two distinct behaviors. If the internal
  2235. "sequential pointer" is valid then BTNextKey ignores the passed
  2236. parameters and returns the next key in sequence. If the internal
  2237. sequential pointer is invalid then BTNextKey uses the passed
  2238. parameters to reposition the sequential pointer. Note that this
  2239. second behavior only occurs if the SearchForSequential option
  2240. has been turned on (as it is by default).
  2241.  
  2242. Based on your description, I would guess that
  2243. SearchForSequential is on and the internal sequential pointer
  2244. is invalid or was never set to begin with. A quick way to test
  2245. this theory would be to turn SearchForSequential off -- in that
  2246. case your call to NextPrevRecord should return 10255 when trying
  2247. to get the next record and 10265 when trying to get the previous
  2248. record.
  2249.  
  2250. You might want to look at the reference section for BTNextKey
  2251. for a more complete discussion of this issue.
  2252.  
  2253. -Terry
  2254.  
  2255.  * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  2256.  
  2257. --- Maximus 2.01wb
  2258.  * Origin: The Programmers Playhouse (1:128/60)
  2259.  * Tossed by SFToss v1.00b on 92/03/19  04:34:21
  2260.  
  2261. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2262.  
  2263. Conference 4
  2264. Date       03-18-92 08:47:08
  2265. From       Terry Hughes
  2266. To         David G. Edwards
  2267. Subject    Why I Like Tp 5.5 Ide (c
  2268.  
  2269.  
  2270. DGE>In a message of <10 Mar 92 13:54:43>, Stephan Patterson (1:240/507.3)
  2271. writes
  2272.  
  2273. DGE> >Like it or not,
  2274. DGE> >SAA/CUA-compliant user interfaces are the way of the future. Most people
  2275. DGE> >prefer them, by far, to the older style interface a la OPRO.
  2276.  
  2277. DGE>I thought OPRO could be used to design SAA/CUA user-interfaces.  Am I off?
  2278.  
  2279.  
  2280. You are correct. OPRO can be used to build CUA compliant
  2281. interfaces by virtue of its flexibility. And OPRO has had
  2282. specific support for dialog boxes (with list boxes, radio
  2283. buttons, check boxes, etc.) since version 1.03.
  2284.  
  2285. -Terry
  2286.  
  2287.  * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  2288.  
  2289. --- Maximus 2.01wb
  2290.  * Origin: The Programmers Playhouse (1:128/60)
  2291.  * Tossed by SFToss v1.00b on 92/03/19  04:34:21
  2292.  
  2293. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2294.  
  2295. Conference 4
  2296. Date       03-18-92 09:03:10
  2297. From       Terry Hughes
  2298. To         Dj Murdoch
  2299. Subject    Re: Binary Tree Linked L
  2300.  
  2301.  
  2302. DM> > Actually B-Trees are more effecient than Binary tress and
  2303. DM> DF>
  2304. DM> DF> I thought the B in B-tree stood for Binary.  What is the
  2305. DM> DF> difference between a b-tree and a binary tree?  (Just a
  2306. DM> DF> basic explanation, I don't want source and such).
  2307.  
  2308. DM>B is for Balanced - to the extent possible, every node has
  2309. DM>the same number of subnodes.  A binary tree can be so
  2310. DM>imbalanced as to be nearly a linked list, if new nodes are
  2311. DM>always added on the right, for instance.
  2312.  
  2313. In the circles that I travel (database toolbox vendors and
  2314. programmers) B-Tree is generally understood to mean Bayer-Tree
  2315. -- Bayer being one of the inventors of this particular
  2316. structure. It's different from a binary tree in that each node
  2317. contains pointers to many subnodes, rather than just left/right
  2318. subnodes and every node must be at least half-full. I believe a
  2319. Bayer-Tree implies balancing as well but I don't have my
  2320. reference here right now to check.
  2321.  
  2322. -Terry
  2323.  
  2324.  * OLX 2.2 * TurboPower Software (voice 719-260-6641)
  2325.  
  2326. --- Maximus 2.01wb
  2327.  * Origin: The Programmers Playhouse (1:128/60)
  2328.  * Tossed by SFToss v1.00b on 92/03/19  04:34:22
  2329.  
  2330. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2331.  
  2332. Conference 4
  2333. Date       03-17-92 23:34:10
  2334. From       Dj Murdoch
  2335. To         All
  2336. Subject    Yet another use for streams
  2337.  
  2338.  My streams unit keeps growing.  The latest addition is a suite of procedures
  2339. that let you use any stream for your overlay buffer.  You say
  2340.  
  2341.   OvrInit('whatever.ovr');
  2342.   OvrInitStream(AStream);
  2343.  
  2344. and it will copy the various overlay segments out to the stream, so that future
  2345. overlay loads come from there.  If you have an XMS stream, you can have your
  2346. overlays buffered in XMS.  If you have a ramdisk, you can buffer just your
  2347. overlays there, without having to copy the whole file over before you run it.
  2348.  
  2349.  
  2350. One nice feature is that you can mix and match:  if you have just a bit of
  2351. EMS, you can use it for a few overlays, put some more in XMS, a few more on
  2352. a ramdisk, and leave the rest on your regular disk.  You can change the allocati
  2353. n dynamically, too. 
  2354.  
  2355. Streams are a lot of fun. 
  2356.  
  2357. --- Msg V3.2
  2358.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  2359.  * Tossed by SFToss v1.00b on 92/03/19  12:33:59
  2360.  
  2361. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2362.  
  2363. Conference 4
  2364. Date       03-19-92 06:14:55
  2365. From       Trevor Carlsen
  2366. To         Dj Murdoch
  2367. Subject    Re: Tp 6.0 Ide
  2368.  
  2369.  
  2370.  
  2371.  TC> That is available in any good programming editor - not just the 
  2372.  TC> IDE.
  2373.  DM> 
  2374.  DM> Read what he wrote - he's talking run-time errors, not compile errors. 
  2375.  
  2376.  DM>  To get those from other editors you generally have to recompile with 
  2377.  
  2378.  DM> the /F option, and retype the address.
  2379.  
  2380. So was I. (Referring to RUN-time errors.)
  2381.  
  2382. TeeCee
  2383.  
  2384. --- TC-ED   v2.01  
  2385.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2386.  * Tossed by SFToss v1.00b on 92/03/20  04:32:24
  2387.  
  2388. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2389.  
  2390. Conference 4
  2391. Date       03-19-92 06:27:46
  2392. From       Trevor Carlsen
  2393. To         Gary Elfert
  2394. Subject    Re: Reading from a text f
  2395.  
  2396.  
  2397.  
  2398.  GE> Could you post an example of how to search for certain text within a
  2399.  GE> text file?  Thanks.
  2400.  
  2401. Download PNL010.* from a BBS near you.  It contains an example of a Boyer-Moore
  2402. search.
  2403.  
  2404. TeeCee
  2405.  
  2406. --- TC-ED   v2.01  
  2407.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2408.  * Tossed by SFToss v1.00b on 92/03/20  04:32:24
  2409.  
  2410. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2411.  
  2412. Conference 4
  2413. Date       03-19-92 06:33:45
  2414. From       Trevor Carlsen
  2415. To         Mark Dixon
  2416. Subject    Re: Hacking the Network
  2417.  
  2418.  
  2419.  
  2420. Take this thread somewhere else.  The subject of this conference is Pascal.
  2421.  
  2422. Trevor Carlsen
  2423. Moderator
  2424.  
  2425. --- TC-ED   v2.01  
  2426.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2427.  * Tossed by SFToss v1.00b on 92/03/20  04:32:25
  2428.  
  2429. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2430.  
  2431. Conference 4
  2432. Date       03-19-92 06:52:09
  2433. From       Trevor Carlsen
  2434. To         Tim Bogel
  2435. Subject    virus
  2436.  
  2437.  
  2438.  
  2439. In a message in the PASCAL conference 15 March 92
  2440. and addressed to All, Tim Bogel (1:120/320) writes:
  2441.  
  2442.  TB>    Does anyone know how to make a virus through pascal, if it is even 
  2443.  
  2444.  TB> possible, and if so how can I go about making one? 
  2445.  
  2446. Anyone responding positively to this request can expect to be excommunicated
  2447. from this conference with no warning given.  Bogel (and his sysop) have been
  2448. netmailed.
  2449.  
  2450. Trevor Carlsen
  2451. Moderator.
  2452.  
  2453.  
  2454.  
  2455. --- TC-ED   v2.01  
  2456.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2457.  * Tossed by SFToss v1.00b on 92/03/20  04:32:25
  2458.  
  2459. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2460.  
  2461. Conference 4
  2462. Date       03-19-92 07:08:38
  2463. From       Trevor Carlsen
  2464. To         ANDREW BROUGHTON
  2465. Subject    Re: Variable-Length Records
  2466.  
  2467.  
  2468.  
  2469.  AB> The database already exists, and will be updated maybe only once a 
  2470.  AB> year or so, so the updating procedure does not have to be fast or 
  2471.  AB> careful. The main problem is, the database is about 4 megs, containing 
  2472.  
  2473.  AB> more than 250,000 SINGLE FIELD records. Now to create an index file is 
  2474.  
  2475.  AB> the usual way, but the index file would be as big as the database 
  2476.  AB> file!...
  2477.  
  2478. Perhaps you misunderstand the function of the suggested index file.  All the
  2479. index file needs to do is give you the offset of each record in the file.
  2480.  As the file is about 4MB, the index file can be as small as 3 bytes per record.
  2481. (4 bytes if you don't feel like writing routines for a 3 byte integer type.)
  2482. Therefore it need not exceed 750K for 250K records and whilst that is still
  2483. a 18% increase in storage space requirements, it may well be worth it.
  2484.  
  2485.  AB> ... The original database is already sorted...
  2486.  
  2487. An index file is certainly the fastest and IMHO the best way to solve the
  2488. problem.
  2489.  
  2490. You provide no indication of what information the data base contains other
  2491. than it being single field.  If you choose a 4 byte index record the 10 msbits
  2492. would be available for some kind of information that might further reduce
  2493. the need to acces the main file.
  2494.  
  2495. TeeCee
  2496.  
  2497. --- TC-ED   v2.01  
  2498.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2499.  * Tossed by SFToss v1.00b on 92/03/20  04:32:25
  2500.  
  2501. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2502.  
  2503. Conference 4
  2504. Date       03-19-92 07:27:58
  2505. From       Trevor Carlsen
  2506. To         Mark Farnan
  2507. Subject    Btrieve Programmers
  2508.  
  2509.  
  2510.  
  2511.  MF> Not yet, but I would like to learn about it, Have you or anybody else 
  2512.  
  2513.  MF> got some good source/reference material regarding FAST database 
  2514.  MF> programming ??, my problem is i need a database where a record is NOT 
  2515.  
  2516.  MF> a set length, and it also may grow but up to 200 bytes per record at 
  2517.  
  2518.  MF> anytime.  I DO  NOT want to allcocate this wasted space when i start 
  2519.  
  2520.  MF> because 200 bytes x 4000 records is ALOT of room, and only some 
  2521.  MF> records may grow, etc, etc.
  2522.  
  2523. Have you got the B-File package from Turbo Power?
  2524.  
  2525. TeeCee
  2526.  
  2527. --- TC-ED   v2.01  
  2528.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2529.  * Tossed by SFToss v1.00b on 92/03/20  04:32:25
  2530.  
  2531. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2532.  
  2533. Conference 4
  2534. Date       03-19-92 07:29:35
  2535. From       Trevor Carlsen
  2536. To         Jud Mccranie
  2537. Subject    Re: Why I Like Tp 5.5 Ide More Than 6.0
  2538.  
  2539.  
  2540.  
  2541.  JM> I sometimes use $IFDEF test, but usually I want to test at that
  2542.  JM> location only temporarily.  I need to remember to remove it.
  2543.  
  2544. Why?  That is the whole point of compiler conditionals!  They allow you to
  2545. leave these extras there without them affecting your executable by just changing
  2546. one define right at the start of your code.
  2547.  
  2548. Even if you wish to remove them at some later time they make things easier.
  2549.  
  2550. TeeCee
  2551.  
  2552. --- TC-ED   v2.01  
  2553.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2554.  * Tossed by SFToss v1.00b on 92/03/20  04:32:26
  2555.  
  2556. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2557.  
  2558. Conference 4
  2559. Date       03-19-92 07:33:58
  2560. From       Trevor Carlsen
  2561. To         Jud Mccranie
  2562. Subject    Re: hiya
  2563.  
  2564.  
  2565.  
  2566.  JM> randomize doesn't produce a more random number - it just keeps it
  2567.  JM> from generating the same sequence each time.
  2568.  
  2569. I realise that the following might be construed as taking pedanticism to extreme
  2570. , and I'm sure you know what Randomize does, but it doesn't really produce
  2571. a different sequence of numbers at all, just ensures a different starting
  2572. point in a "master" sequence which is reasonably unpredictable due to the
  2573. way it seeds RandSeed *providing* it is not repeatedly called within the same
  2574. clock tick.
  2575.  
  2576. Now the reason for my pendantics is because some may have interpreted your
  2577. statement to mean that use of the Randomize procedure will ensure a seemingly
  2578. different entry point for the sequence of numbers each time it used.  Because
  2579. of the manner in which it obtains the value it assigns RandSeed, this is only
  2580. true if different calls do not occur within the same clock tick.  It also
  2581. means there are only 1,573,040 possible starting numbers each day even though
  2582. Borland's algorithm has a much longer "period".
  2583.  
  2584. TeeCee
  2585.  
  2586. --- TC-ED   v2.01  
  2587.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2588.  * Tossed by SFToss v1.00b on 92/03/20  04:32:26
  2589.  
  2590. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2591.  
  2592. Conference 4
  2593. Date       03-19-92 18:23:39
  2594. From       Trevor Carlsen
  2595. To         Jim Starke
  2596. Subject    Input Routine (1 of 3)
  2597.  
  2598.  
  2599.  
  2600.  JS> The only thing I can think of is making a totally new input
  2601.  JS> routine from scratch that will check for the back space, cursor
  2602.  JS> keys, home key, insert key, end key, etc. and re-invent the
  2603.  JS> wheel in other words.
  2604.  
  2605.  JS> Can anyone enlighten me with some code so I don't have to
  2606.  JS> re-invent the wheel?
  2607.  
  2608. Here is a unit that should do what you want...
  2609.  
  2610. unit keyinput;
  2611.  
  2612. { Author Trevor J Carlsen - released into the public domain 1991         }
  2613. {        PO Box 568                                                      }
  2614. {        Port Hedland                                                    }
  2615. {        Western Australia 6721                                          }
  2616. {        Voice +61 91 73 2026  Data +61 91 73 2569                       }
  2617. {        FidoNet 3:690/644                                               }
  2618.  
  2619. { This unit is designed to permit controlled input into a pre-determined }
  2620. { field size.  It also provides some handy associated procedures and     }
  2621. { functions and constants.                                               }
  2622.  
  2623. interface
  2624.  
  2625. uses crt;
  2626.  
  2627. const
  2628.   F1  = $3b00; ShF1  = $5400; CtrlF1  = $5e00; AltF1  = $6800;
  2629.   F2  = $3c00; ShF2  = $5500; CtrlF2  = $5f00; AltF2  = $6900;
  2630.   F3  = $3d00; ShF3  = $5600; CtrlF3  = $6000; AltF3  = $6a00;
  2631.   F4  = $3e00; ShF4  = $5700; CtrlF4  = $6100; AltF4  = $6b00;
  2632.   F5  = $3f00; ShF5  = $5800; CtrlF5  = $6200; AltF5  = $6c00;
  2633.   F6  = $4000; ShF6  = $5900; CtrlF6  = $6300; AltF6  = $6d00;
  2634.   F7  = $4100; ShF7  = $5a00; CtrlF7  = $6400; AltF7  = $6e00;
  2635.   F8  = $4200; ShF8  = $5b00; CtrlF8  = $6500; AltF8  = $6f00;
  2636.   F9  = $4300; ShF9  = $5c00; CtrlF9  = $6600; AltF9  = $7000;
  2637.   F10 = $4400; ShF10 = $5d00; CtrlF10 = $6700; AltF10 = $7100;
  2638.  
  2639.   BackSpace    = $0e08; CtrlBackSpace = $0e7f;
  2640.   Tab          = $0f09; Tab_left      = $0f00;
  2641.   Enter        = $1c0d; CtrlEnter     = $1c0a;
  2642.   InsertKey    = $5200; DeleteKey     = $5300;
  2643.   Home         = $4700; CtrlHome      = $7700;
  2644.   Endkey       = $4f00; CtrlEnd       = $7500;
  2645.   PageUp       = $4900; CtrlPageUp    = $8400;
  2646.   PageDn       = $5100; CtrlPageDown  = $7600;
  2647.   UpArrow      = $4800; DownArrow     = $5000;
  2648.   LeftArrow    = $4b00; CtrlLeftArrow = $7300;
  2649.   RightArrow   = $4d00; CtrlRightArrow= $7400;
  2650.   Escape       = $011b;
  2651.  
  2652. type
  2653.   CursorState  = (Off, On, Normal, Block);
  2654.  
  2655. const
  2656.   InsertOn : boolean = false;
  2657.  
  2658. procedure Beep(freq,len: word);
  2659. function  CursorStatus: CursorState;
  2660. procedure Cursor(Action: CursorState);
  2661. procedure NormalCursor;
  2662. procedure HiddenCursor;
  2663. procedure BlockCursor;
  2664. function  ReadStr(width   : word;
  2665.                   prompt  : string;
  2666.                   attr    : byte;
  2667.                   s       : string) : string;
  2668.  
  2669. implementation
  2670.  
  2671. var
  2672.   OriginalStatus : CursorState;
  2673.   OldExitProc    : pointer;
  2674.  
  2675. procedure Beep(freq,len : word);
  2676.   { Beeps the speaker for len thousandths of a second }
  2677.   begin
  2678.     Sound(freq);
  2679.     delay(len);
  2680.     NoSound;
  2681.   end;  { Beep }
  2682.  
  2683. function CursorStatus: CursorState;
  2684.   var
  2685.     bottom: byte absolute $40:$60;
  2686.     top   : byte absolute $40:$61;
  2687.     x     : shortint;
  2688.   begin
  2689.     x     := bottom - top;
  2690.     if x < 0 then
  2691.       CursorStatus := Off
  2692.     else if x = 1 then
  2693.       CursorStatus := Normal
  2694.     else if x > 1 then
  2695.       CursorStatus := Block
  2696.     else CursorStatus := On;
  2697.   end;  { CursorStatus }
  2698.  
  2699.  
  2700. Continued next message...
  2701.  
  2702.  
  2703.  
  2704.  
  2705. --- TC-ED   v2.01  
  2706.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2707.  * Tossed by SFToss v1.00b on 92/03/20  04:32:26
  2708.  
  2709. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2710.  
  2711. Conference 4
  2712. Date       03-19-92 18:21:05
  2713. From       Trevor Carlsen
  2714. To         Jim Starke
  2715. Subject    Input Routine (2 of 3)
  2716.  
  2717.  
  2718.  
  2719. ... continued from previous message.
  2720.  
  2721. procedure Cursor(Action : CursorState);
  2722.   { Turn the cursor on/off or make it a block}
  2723.  
  2724.   procedure ChangeCursor(top,bottom : byte);
  2725.     begin
  2726.       asm
  2727.         mov ah, $01
  2728.         mov ch, top
  2729.         mov cl, bottom
  2730.         int $10
  2731.       end;
  2732.     end; { ChangeCursor}
  2733.  
  2734. begin
  2735.   case action of
  2736.     On     : if LastMode = Mono then
  2737.                 ChangeCursor($0C,$0C)
  2738.               else
  2739.                 ChangeCursor($06,$06);
  2740.     Normal : if LastMode = Mono then
  2741.                ChangeCursor($0B,$0C)
  2742.              else
  2743.                ChangeCursor($06,$07);
  2744.     Off    : ChangeCursor($20,$00);
  2745.     Block  : if LastMode = Mono then
  2746.                ChangeCursor($02,$0C)
  2747.              else
  2748.                ChangeCursor($02,$07);
  2749.   end; { case}
  2750. end;  { ChangeCursor}
  2751.  
  2752. procedure NormalCursor;
  2753.   begin
  2754.     Cursor(On);
  2755.   end; { NormalCursor }
  2756.  
  2757. procedure HiddenCursor;
  2758.   begin
  2759.     Cursor(Off);
  2760.   end; { HiddenCursor }
  2761.  
  2762. procedure BlockCursor;
  2763.   begin
  2764.     Cursor(Block);
  2765.   end;  { BlockCursor }
  2766.  
  2767. function KeyWord : word; assembler;
  2768.   { Returns a word value where the msb is the scan code of a keypress    }
  2769.   { and the lsb is the asciiz value of the key.                          }
  2770.   asm
  2771.     mov  ax,0
  2772.     int  16h
  2773.   end;  { KeyWord }
  2774.  
  2775.  
  2776. Continued next message ...
  2777.  
  2778.  
  2779.  
  2780.  
  2781. --- TC-ED   v2.01  
  2782.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2783.  * Tossed by SFToss v1.00b on 92/03/20  04:32:27
  2784.  
  2785. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2786.  
  2787. Conference 4
  2788. Date       03-19-92 18:22:33
  2789. From       Trevor Carlsen
  2790. To         Jim Starke
  2791. Subject    Input Routine  (3 of 3)
  2792.  
  2793.  
  2794.  
  2795. ...continued from previous message.
  2796.  
  2797.  
  2798. function  ReadStr(width   : word;
  2799.                   prompt  : string;
  2800.                   attr    : byte;
  2801.                   s       : string) : string;
  2802.  
  2803. {   Editing keys are -                                                   }
  2804. {     DeleteKey        - DeleteKeys character at the cursor.             }
  2805. {     LeftArrow        - Nondestructive move cursor to the left.         }
  2806. {     RightArrow       - Nondestructive move cursor to the right.        }
  2807. {     End              - Move cursor to end of input string.             }
  2808. {     Home             - Move cursor to start of input string.           }
  2809. {     Backspace        - DeleteKeys character to the left of cursor.     }
  2810. {     escape           - Aborts routine which then returns just an       }
  2811. {                        escape character - regardless of what           }
  2812. {                        characters were previously entered.             }
  2813. {     return/enter     - Leaves routine with string returned.            }
  2814.  
  2815. {   Width = The width of the input field.  Once input reaches the width  }
  2816. {           required, no further characters are accepted.                }
  2817. {   prompt= A prompt will be displayed in the current attribute.  If no  }
  2818. {           prompt is required pass a nul string.                        }
  2819. {   attr  = The input field will be displayed in attr colour.            }
  2820. {   s     = s will be displayed in the input field and the cursor will   }
  2821. {           be positioned at the end of the s string.                    }
  2822.  
  2823. {   Example:                                                             }
  2824. {      st := ReadStr(20,'Enter Name: ',LtGrayOnBlue,st);                 }
  2825. {      ( st MUST be initialised in the above example before the call. )  }
  2826.  
  2827. const
  2828.     space = #32;
  2829.   var
  2830.     xpos, ypos,
  2831.     stpos,OldAttr : byte;
  2832.     len           : byte absolute s;
  2833.     finished      : boolean;
  2834.     key           : word;
  2835.     ch            : char absolute key;
  2836.  
  2837.   procedure WriteField;
  2838.     var x : byte;
  2839.     begin
  2840.       GotoXY(xpos,ypos);
  2841.       for x := 1 to width do
  2842.         write(space);
  2843.       GotoXY(xpos,ypos);
  2844.     end; { WriteField }
  2845.  
  2846.   procedure DeleteChar;
  2847.     begin
  2848.       Delete(s,stpos,1);
  2849.       s := s + space;
  2850.       gotoXY(xpos,ypos);
  2851.       write(s);
  2852.       dec(len);
  2853.     end;  { DeleteChar }
  2854.  
  2855.   procedure AddChar;
  2856.     { Checks that it is valid to insert or add a character to input str }
  2857.     begin
  2858.       if InsertOn then begin
  2859.         if (len < width) then begin
  2860.           move(s[stpos],s[succ(stpos)],width-pred(stpos));
  2861.           inc(len);
  2862.           s[stpos] := ch;
  2863.           inc(stpos);
  2864.         end
  2865.         else beep(450,15);
  2866.       end else begin
  2867.         if stpos <= width then begin
  2868.           s[stpos] := ch;
  2869.           if stpos > len then
  2870.             inc(len);
  2871.           inc(stpos);
  2872.         end else beep(450,15);
  2873.       end;
  2874.     end; { AddChar }
  2875.  
  2876.   begin
  2877.     finished      := false;
  2878.     OldAttr       := TextAttr;
  2879.     write(prompt);
  2880.     TextAttr      := attr;
  2881.     xpos          := WhereX;
  2882.     ypos          := WhereY;
  2883.     WriteField;
  2884.     stpos         := succ(len);
  2885.     repeat
  2886.       GotoXY(xpos,ypos);
  2887.       write(s);
  2888.       GotoXY(xpos + pred(stpos),ypos);
  2889.       if InsertOn then
  2890.         Cursor(Block)
  2891.       else
  2892.         Cursor(Normal);
  2893.       key := KeyWord;
  2894.       case key of
  2895.         InsertKey  : InsertOn := not InsertOn;
  2896.         DeleteKey  : if (len > 0) and (stpos > 0) then
  2897.                        DeleteChar;
  2898.         Enter      : begin
  2899.                        ReadStr  := s;
  2900.                        finished := true;
  2901.                      end;
  2902.         BackSpace  : if stpos > 1 then begin
  2903.                        dec(stpos);
  2904.                        DeleteChar;
  2905.                      end
  2906.                      else beep(450,15);
  2907.         Escape     : begin
  2908.                        finished := true;
  2909.                        ReadStr  := ch;
  2910.                        WriteField;
  2911.                        len      := 0;
  2912.                      end;
  2913.         LeftArrow  : if stpos > 1 then dec(stpos);
  2914.         RightArrow : if stpos <= len then inc(stpos);
  2915.         Home       : stpos := 1;
  2916.         EndKey     : stpos := succ(len);
  2917.         else begin case lo(key) of
  2918.                      32..255: AddChar
  2919.                      else beep(450,15);
  2920.                    end; { case lo(key) of }
  2921.              end; { else }
  2922.       end; { case key of }
  2923.     until finished;
  2924.     TextAttr      := OldAttr;
  2925.     writeln;
  2926.   end; { ReadStr }
  2927.  
  2928. procedure KbdExitProc; far;
  2929.   begin
  2930.     ExitProc := OldExitProc;
  2931.     Cursor(OriginalStatus);
  2932.   end;  { KbdExitProc }
  2933.  
  2934. begin
  2935.   { Set up an exit procedure to ensure that the cursor is restored }
  2936.   OldExitProc    := ExitProc;
  2937.   OriginalStatus := CursorStatus;
  2938. end.
  2939.  
  2940.  
  2941.  
  2942. --- TC-ED   v2.01  
  2943.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  2944.  * Tossed by SFToss v1.00b on 92/03/20  04:32:28
  2945.  
  2946. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  2947.  
  2948. Conference 4
  2949. Date       03-19-92 19:37:33
  2950. From       Trevor Carlsen
  2951. To         James Chambers
  2952. Subject    Text Viewer (1 of 3)
  2953.  
  2954.  
  2955.  
  2956.  JC> Does anyone know where I can get the source for a 
  2957.  JC> simple text viewer?
  2958.  JC> I just need to display one 66 line page on screen 
  2959.  JC> and allow scrolling.
  2960.  
  2961. I'm not sure how you intend to display 66 lines on screen.  However here is
  2962. a text viewer that will allow you to view a text file with scrolling capabilitie
  2963. .
  2964.  
  2965. {$A+,B-,D-,E+,F-,I+,L-,N-,O-,R+,S-,V-}
  2966. {$M 4048,65536,655360}
  2967.  
  2968. program Readtext;
  2969.  
  2970. { Author Trevor J Carlsen - released into the public domain 1991         }
  2971. {        PO Box 568                                                      }
  2972. {        Port Hedland                                                    }
  2973. {        Western Australia 6721                                          }
  2974. {        Voice +61 91 73 2026  Data +61 91 73 2569                       }
  2975. {        FidoNet 3:690/644                                               }
  2976.  
  2977. { This example programs displays a text file using simple word wrap. The }
  2978. { cursor keys are used to page forward or backwards by page or by line.  }
  2979. { The program makes some important assumptions.  The main one is that no }
  2980. { line in the file will ever exceed 255 characters in length.  To get    }
  2981. { around this restriction the ReadTxtLine function would need to be      }
  2982. { rewritten.                                                             }
  2983.  
  2984. { The other major restriction is that files exceeding a size able to be  }
  2985. { totally placed in RAM cannot be viewed.                                }
  2986.  
  2987. {.$DEFINE TurboPower (Remove the period if you have Turbo Power's TPro)  }
  2988.  
  2989. uses
  2990.   {$IFDEF TurboPower }
  2991.   tpcrt,
  2992.   colordef;
  2993.   {$ELSE}
  2994.   crt;
  2995.   {$ENDIF}
  2996.  
  2997. const
  2998.   {$IFNDEF TurboPower }
  2999.   BlackOnLtGray = $70;      LtGrayOnBlue = $17;
  3000.   {$ENDIF}
  3001.   LineLength    = 79;       MaxLines     = 6000;
  3002.   ScreenLines   = 22;       escape       = $011b;
  3003.   Home          = $4700;    _end         = $4f00;
  3004.   upArrow       = $4800;    downArrow    = $5000;
  3005.   PageUp        = $4900;    PageDown     = $5100;
  3006.  
  3007. type
  3008.   LineStr    = string[Linelength];
  3009.   StrPtr     = ^LineStr;
  3010.  
  3011. var
  3012.   TxtFile    : text;
  3013.   Lines      : array[1..MaxLines] of StrPtr;
  3014.   NumberLines: 1..MaxLines+1;
  3015.   CurrentLine: 1..MaxLines+1-ScreenLines;
  3016.   st         : string;
  3017.   finished   : boolean;
  3018.   OldExitProc: pointer;
  3019.   TxtBuffer  : array[0..16383] of byte;
  3020.  
  3021. function LastPos(ch : char; S : string): byte;
  3022.   { Returns the last position of ch in S or zero if ch not in S }
  3023.   var
  3024.     x   : word;
  3025.     len : byte absolute S;
  3026.   begin
  3027.     x := succ(len);
  3028.     repeat
  3029.       dec(x);
  3030.     until (x = 0) or (S[x] = ch);
  3031.     LastPos := x;
  3032.   end;  { LastPos }
  3033.  
  3034.  
  3035. continued in next message ...
  3036.  
  3037.  
  3038. --- TC-ED   v2.01  
  3039.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  3040.  * Tossed by SFToss v1.00b on 92/03/20  04:32:28
  3041.  
  3042. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3043.  
  3044. Conference 4
  3045. Date       03-19-92 19:41:56
  3046. From       Trevor Carlsen
  3047. To         James Chambers
  3048. Subject    Text Viewer (2 of 3)
  3049.  
  3050.  
  3051.  
  3052. ... continued from previous message.
  3053.  
  3054. function Wrap(var S,CarryOver: string): string;
  3055.   { Returns a string of maximum length Linelength from S. Any additional }
  3056.   { characters remaining are placed into CarryOver.                      }
  3057.   const
  3058.     space = #32;
  3059.   var
  3060.     temp      : string;
  3061.     LastSpace : byte;
  3062.     len       : byte absolute S;
  3063.   begin
  3064.     FillChar(temp,sizeof(temp),32);
  3065.     temp := S; CarryOver := ''; wrap := temp;
  3066.     if length(temp) > LineLength then begin
  3067.       LastSpace := LastPos(space,copy(temp,1,LineLength+1));
  3068.       if LastSpace <> 0 then begin
  3069.         Wrap[0]   := chr(LastSpace - 1);
  3070.         CarryOver := copy(temp,LastSpace + 1, 255)
  3071.       end  { if LastSpace... }
  3072.       else begin
  3073.         Wrap[0]   := chr(len);
  3074.         CarryOver := copy(temp,len,255);
  3075.       end; { else }
  3076.     end; { if (length(S))...}
  3077.   end;  { Wrap }
  3078.  
  3079. function ReadTxtLine(var f: text; L: byte): string;
  3080.   var
  3081.     temp : string;
  3082.     len  : byte absolute temp;
  3083.     done : boolean;
  3084.   begin
  3085.     len := 0; done := false;
  3086.     {$I-}
  3087.     while not eoln(f) do begin
  3088.       read(f,temp);
  3089.       if IOResult <> 0 then begin
  3090.         writeln('Error reading file - aborted');
  3091.         halt;
  3092.       end;
  3093.     end; { while }
  3094.     if eoln(f) then readln(f);
  3095.     ReadTxtLine := st + Wrap(temp,st);
  3096.     finished := eof(f);
  3097.   end;  { ReadTxtLine }
  3098.  
  3099. procedure ReadTxtFile(var f: text);
  3100.   var
  3101.     x : word;
  3102.   begin
  3103.     st          := '';
  3104.     NumberLines := 1;
  3105.     repeat
  3106.       if NumberLines > MaxLines then begin
  3107.         writeln('File too big');
  3108.         halt;
  3109.       end;
  3110.       if (MaxAvail >= Sizeof(LineStr)) then
  3111.         new(Lines[NumberLines])
  3112.       else begin
  3113.         writeln('Insufficient memory');
  3114.         halt;
  3115.       end;
  3116.       FillChar(Lines[NumberLines]^,LineLength+1,32);
  3117.       if length(st) > LineLength then
  3118.         Lines[NumberLines]^  := wrap(st,st)
  3119.       else if length(st) <> 0 then begin
  3120.         Lines[NumberLines]^  := st;
  3121.         st := '';
  3122.       end else
  3123.         Lines[NumberLines]^  := ReadTxtLine(f,LineLength+1);
  3124.       Lines[NumberLines]^[0] := chr(LineLength);
  3125.       if not finished then
  3126.         inc(NumberLines);
  3127.     until finished;
  3128.   end;  { ReadTxtFile }
  3129.  
  3130. procedure DisplayScreen(line: word);
  3131.   var
  3132.     x : byte;
  3133.   begin
  3134.     GotoXY(1,1);
  3135.     for x := 1 to ScreenLines - 1 do
  3136.       writeln(Lines[x-1+line]^);
  3137.     write(Lines[x+line]^)
  3138.   end;
  3139.  
  3140. procedure PreviousPage;
  3141.   begin
  3142.     if CurrentLine > ScreenLines then
  3143.       dec(CurrentLine,ScreenLines-1)
  3144.     else
  3145.       CurrentLine := 1;
  3146.   end;  { PreviousPage }
  3147.  
  3148. continued in next message ...
  3149.  
  3150. --- TC-ED   v2.01  
  3151.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  3152.  * Tossed by SFToss v1.00b on 92/03/20  04:32:29
  3153.  
  3154. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3155.  
  3156. Conference 4
  3157. Date       03-19-92 19:44:03
  3158. From       Trevor Carlsen
  3159. To         James Chambers
  3160. Subject    Text Viewer (3 of 3)
  3161.  
  3162.  
  3163.  
  3164. ... continued from previous message.
  3165. procedure NextPage;
  3166.   begin
  3167.     if CurrentLine < (succ(NumberLines) - ScreenLines * 2) then
  3168.       inc(CurrentLine,ScreenLines-1)
  3169.     else CurrentLine := succ(NumberLines) - ScreenLines;
  3170.   end;   { NextPage }
  3171.  
  3172. procedure PreviousLine;
  3173.   begin
  3174.     if CurrentLine > 1 then dec(CurrentLine)
  3175.     else CurrentLine := 1;
  3176.   end;  { PreviousLine }
  3177.  
  3178. procedure NextLine;
  3179.   begin
  3180.     if CurrentLine < (succ(NumberLines) - ScreenLines) then
  3181.       inc(CurrentLine)
  3182.     else CurrentLine := succ(NumberLines) - ScreenLines;
  3183.   end; { NextLine }
  3184.  
  3185. procedure StartOfFile;
  3186.   begin
  3187.     CurrentLine := 1;
  3188.   end; { StartOfFile }
  3189.  
  3190. procedure EndOfFile;
  3191.   begin
  3192.     CurrentLine := succ(NumberLines) - ScreenLines;
  3193.   end;  { EndOfFile }
  3194.  
  3195. procedure DisplayFile;
  3196.  
  3197.   function KeyWord : word; assembler;
  3198.     asm
  3199.       mov  ah,0
  3200.       int  16h
  3201.     end;
  3202.  
  3203.   begin
  3204.     DisplayScreen(CurrentLine);
  3205.     repeat
  3206.       case KeyWord of
  3207.         PageUp    : PreviousPage;
  3208.         PageDown  : NextPage;
  3209.         UpArrow   : PreviousLine;
  3210.         DownArrow : NextLine;
  3211.         Home      : StartOfFile;
  3212.         _End      : EndOfFile;
  3213.         Escape    : halt;
  3214.       end; { case }
  3215.       DisplayScreen(CurrentLine);
  3216.     until false;
  3217.   end; { DisplayFile }
  3218.  
  3219. {$IFDEF TurboPower}
  3220. procedure NewExitProc;far;
  3221.   begin
  3222.     ExitProc := OldExitProc;
  3223.     NormalCursor;
  3224.   end;
  3225. {$ENDIF}
  3226.  
  3227. procedure Initialise;
  3228.   begin
  3229.     CurrentLine := 1;
  3230.     if ParamCount <> 1 then begin
  3231.       writeln('No file name parameter');
  3232.       halt;
  3233.     end;
  3234.     assign(TxtFile,Paramstr(1));
  3235.     {$I-}  reset(TxtFile);
  3236.     if IOResult <> 0 then begin
  3237.       writeln('Unable to open ',Paramstr(1));
  3238.       halt;
  3239.     end;
  3240.     SetTextBuf(TxtFile,TxtBuffer);
  3241.     Window(1,23,80,25);
  3242.     TextAttr := BlackOnLtGray;
  3243.     clrscr;
  3244.     writeln
  3245. ('              Next Page = [PageDown]     Previous Page = [PageUp]');
  3246.     writeln
  3247. ('              Next Line = [DownArrow]    Previous Line = [UpArrow]');
  3248.     write
  3249. ('         Start of File = [Home]   End of File = [End]   Quit = [Escape]');
  3250.     Window(1,1,80,22);
  3251.     TextAttr := LtGrayOnBlue;
  3252.     clrscr;
  3253.     {$IFDEF TurboPower}
  3254.     HiddenCursor;
  3255.     OldExitProc := ExitProc;
  3256.     ExitProc    := @NewExitProc;
  3257.     {$ENDIF}
  3258.   end;
  3259.  
  3260. begin
  3261.   Initialise;
  3262.   ReadTxtFile(TxtFile);
  3263.   DisplayFile;
  3264. end.
  3265.  
  3266.  
  3267. --- TC-ED   v2.01  
  3268.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  3269.  * Tossed by SFToss v1.00b on 92/03/20  04:32:29
  3270.  
  3271. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3272.  
  3273. Conference 4
  3274. Date       03-18-92 19:47:00
  3275. From       Norbert Igl
  3276. To         Chris Elris
  3277. Subject    my bed
  3278.  
  3279.  
  3280.  
  3281.  
  3282.  
  3283.  > SL> tied to the bed and lick you all over.  i then would move down to
  3284.  > SL> and suck it hard.....
  3285.  > great babe, your bed or mine?!?!
  3286.  
  3287.   ??????  ..... hmmmmm  (:-))
  3288.  
  3289. ---
  3290.  * Origin: Let's talk about hex, baby.... (2:241/5300.3)
  3291.  * Tossed by SFToss v1.00b on 92/03/20  11:33:04
  3292.  
  3293. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3294.  
  3295. Conference 4
  3296. Date       03-18-92 17:28:17
  3297. From       Dj Murdoch
  3298. To         Jud Mccranie
  3299. Subject    Re: Why I Like Tp 5.5 Ide (continued)
  3300.  
  3301.   JM> What if you had to think about which pedal to press each time while
  3302.  JM> driving?  That would be a mess.  But with the 6.0 IDE you have to
  3303.  JM> think about it each time, unlike the previous versions.
  3304.  
  3305. Come on, that's just nonsense.  *You* have to think about it, because you're
  3306. new to the 6.0 IDE.  Anyone who uses it much learns the new keys just the
  3307. way you learned the old Wordstar keys.
  3308.  
  3309.  
  3310. --- Msg V3.2
  3311.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  3312.  * Tossed by SFToss v1.00b on 92/03/20  11:34:20
  3313.  
  3314. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3315.  
  3316. Conference 4
  3317. Date       03-18-92 17:31:14
  3318. From       Dj Murdoch
  3319. To         Mike Wilson
  3320. Subject    Re: Runtime Error 200 On An Xt.
  3321.  
  3322.   MW> Okay, what would you use for a do all catch all {$g+} 
  3323.  MW> grep?  I think I have tried the -l but I have tried 
  3324.  MW> everything else I can find and this still seems to be a problem...
  3325.  
  3326. I'd use:
  3327.  
  3328.   grep -r- -i+ "g+" *.*
  3329.  
  3330. and probably turn up a fair bit of junk, but would be sure to turn up what
  3331. I was looking for if it was there.
  3332.  
  3333. --- Msg V3.2
  3334.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  3335.  * Tossed by SFToss v1.00b on 92/03/20  11:34:20
  3336.  
  3337. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3338.  
  3339. Conference 4
  3340. Date       03-18-92 17:32:34
  3341. From       Dj Murdoch
  3342. To         David G. Edwards
  3343. Subject    Re: Pascal Structure Philosophy
  3344.  
  3345.   DG> That brings up something I'd like to see in a future 
  3346.  DG> version of TP: I'd like to look at the compiler's output 
  3347.  DG> like the CPU window in TD.
  3348.  
  3349.  You know about my DUMPPROG utility?  It does a dump something like the TD
  3350. window.  I'm thinking about a new release; just looking for a 486-aware disassem
  3351. ler first.  Once I get that, I'll finish off some work I've done on resolving
  3352. numeric addresses as symbolic names.
  3353.  
  3354. --- Msg V3.2
  3355.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  3356.  * Tossed by SFToss v1.00b on 92/03/20  11:34:20
  3357.  
  3358. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3359.  
  3360. Conference 4
  3361. Date       03-18-92 20:21:18
  3362. From       Dj Murdoch
  3363. To         Dale Frakes
  3364. Subject    Re: Variable # parameters
  3365.  
  3366.   DF> Does anyone out there know how to write a pascal (TP 6.0) 
  3367.  DF> function or procedure that accepts a variable number of 
  3368.  DF> parameters.  I assume this is possible, since Write, 
  3369.  DF> Writeln, Read, Readln, Concat, etc all accept variable 
  3370.  DF> number of parameters, and they are written in Pascal.  Has 
  3371.  DF> someone who has seen the source for the Run Time Libraries 
  3372.  DF> know how this is done?  Again, I would assume that if 
  3373.  DF> someone can compile the RTL, it can be done within the Pascal environment.
  3374.  
  3375. No, you can't do it even if you have the RTL, unless you want to call your
  3376. procedure Writeln, Read, Readln, Concat, etc., and lose access to the real
  3377. one.  Those names are hard coded into a part of the RTL for which you don't
  3378. get source (it's not Pascal, it's probably produced by another program), and
  3379. the compiler has special code for those particular functions/procedures and
  3380. no others.
  3381.  
  3382. One solution is the one used by TurboVision:  have your function work on lists
  3383. and produce a pointer to a list, so that you can just add parentheses to your
  3384. heart's content (see the TV manual for examples).  I think a better solution
  3385. is to just live with the fact that the number of parameters is fixed, and
  3386. design around it.
  3387.  
  3388. What particular use do you have in mind?
  3389.  
  3390.  
  3391. --- Msg V3.2
  3392.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  3393.  * Tossed by SFToss v1.00b on 92/03/20  11:34:20
  3394.  
  3395. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3396.  
  3397. Conference 4
  3398. Date       03-18-92 20:31:22
  3399. From       Dj Murdoch
  3400. To         Chris Long
  3401. Subject    Re: Obsolete pascal??
  3402.  
  3403.   CL> -> Hi everyone!  I would like to know if the Pascal Language is going to
  3404.  
  3405.  CL> -> become obsolute in the next 5 years!  
  3406.  
  3407.  CL> Nonsense.  The language is powerful, flexible, easy to 
  3408.  CL> learn, and fun to program in.  Those are winning 
  3409.  CL> attributes...  Of course, the industry has adopted C as 
  3410.  CL> its preferred language, so C will undoubtedly be more 
  3411.  CL> popular than pascal....  But, that will not make the language obsolete.
  3412.  
  3413. I'd say that Standard Pascal is close to obsolete right now.  I would never
  3414. use it, nor would I recommend that anyone else use it.  Turbo Pascal, on the
  3415. other hand, is a useful language that will probably still be popular in 5
  3416. years.  It's not compliant with the Pascal standard, though, so I wouldn't
  3417. call it Pascal.
  3418.  
  3419. It's possible that Extended Pascal will be around in 5 years.  I don't know
  3420. if it will catch on or not; I tend to doubt it, but hope otherwise.  Its big
  3421. problem is that Turbo Pascal isn't compatible with it either, so it doesn't
  3422. really stand a chance on the PC unless Borland chooses to adopt it.
  3423.  
  3424.  
  3425. --- Msg V3.2
  3426.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  3427.  * Tossed by SFToss v1.00b on 92/03/20  11:34:21
  3428.  
  3429. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3430.  
  3431. Conference 4
  3432. Date       03-19-92 08:20:53
  3433. From       Dj Murdoch
  3434. To         ANDREW BROUGHTON
  3435. Subject    Re: Variable-Length Records
  3436.  
  3437.   AB> Thanks for replying. I thought of that, but my situation 
  3438.  AB> is unique. The database already exists, and will be 
  3439.  AB> updated maybe only once a year or so, so the updating 
  3440.  AB> procedure does not have to be fast or careful. The main 
  3441.  AB> problem is, the database is about 4 megs, containing more 
  3442.  AB> than 250,000 SINGLE FIELD records. Now to create an index 
  3443.  AB> file is the usual way, but the index file would be as big 
  3444.  AB> as the database file! 
  3445.  
  3446. Don't put keys into the index file, just put the offset of the start of the
  3447. corresponding record.  Because of the size, you'll need to use longint offsets;
  3448. that means the index will be about 1 Meg.  It might be worth your while to
  3449. do some fiddling and create 3 byte integers; that would reduce the size of
  3450. the index to 750K.
  3451.  
  3452.  AB> So far, I can only see 2 ways 
  3453.  AB> to deal with this: One is to copy the database over, and 
  3454.  AB> make each record the same length, (and probably doubling 
  3455.  AB> the size), or just do the binary search as if the file 
  3456.  AB> were made up of records all of the same size, and when the 
  3457.  AB> seek is done, increment or decrement the file pointer 
  3458.  AB> until it is on the start of a record, then check it, then 
  3459.  AB> continue the search. 
  3460.  
  3461. The second method would work well, if you could easily recognize the start
  3462. of a record.  If they contain binary data, that won't be easy.  If they're
  3463. just text strings, and you're sure certain characters will never occur (e.g.
  3464.  high ascii, or control characters) you could easily construct a signature
  3465. to put at the start of a record that couldn't possibly occur anywhere else. 
  3466.  
  3467.  
  3468.  
  3469. --- Msg V3.2
  3470.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  3471.  * Tossed by SFToss v1.00b on 92/03/20  11:34:21
  3472.  
  3473. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3474.  
  3475. Conference 4
  3476. Date       03-19-92 08:30:55
  3477. From       Dj Murdoch
  3478. To         Jud Mccranie
  3479. Subject    Re: TP 6 Bad design
  3480.  
  3481.   JM> I ran them from EXE files.  To be sure, I did it again.
  3482.  
  3483.  JM> TP   286   seconds
  3484.  
  3485.  JM> 5.5  N/A   22.24
  3486.  JM> 6.0  G-    22.90
  3487.  JM> 6.0  G+    22.96 (even though the EXE was 1.3% smaller than above)
  3488.  
  3489. Did you recompile before re-running?  A significant part of that difference
  3490. could just be load time; if the 5.5 .EXE is contiguous on the disk, near the
  3491. FAT, it'll load noticeably faster than an .EXE that's badly fragmented.
  3492.  
  3493. Another possibility is that your disk cache may have the 5.5 code already
  3494. in it (because it's on the disk near something that you've just used).
  3495.  
  3496. Timing .EXEs isn't easy.  I'd only trust the timings if you've been running
  3497. them from a ramdisk.
  3498.  
  3499. --- Msg V3.2
  3500.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  3501.  * Tossed by SFToss v1.00b on 92/03/20  11:34:21
  3502.  
  3503. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3504.  
  3505. Conference 4
  3506. Date       03-19-92 08:35:43
  3507. From       Dj Murdoch
  3508. To         Joshua Kersey @ 930/22
  3509. Subject    Re: Are you listening... ?
  3510.  
  3511.  JJM>    If you don't do scientific or engineering calculations...  JJM> there
  3512. is very little in it for you. What I am asking for is a JJM> type REAL exponenti
  3513. tion operator (NOT a function, but an JJM> OPERATOR, like + or * ) which can
  3514. raise a real number to a real JJM> (non-integer) power.
  3515.  
  3516.  JK> Ahhh...I seee, yes, I've been needing one too, and yes, 
  3517.  JK> I'll agree! "**" Does sound like a very good operator to 
  3518.  JK> use too...good idea. ..
  3519.  
  3520. But JJ isn't ambitious enough.  There's no problem writing a function to raise
  3521. a real number to a real power.  The hard thing is writing an operator that
  3522. raises integers to integer powers, reals to integer powers, or reals to real
  3523. powers, all with the same syntax, and all choosing efficient ways to do the
  3524. calculation.
  3525.  
  3526. For example,
  3527.  
  3528.    Pi**2.0
  3529.  
  3530. should be calculated as Exp(2.0*ln(Pi)), but
  3531.  
  3532.   Pi**2
  3533.  
  3534. should be calculated as Pi*Pi, and 
  3535.  
  3536.   2**10
  3537.  
  3538. should be calculated as 1 shl 10.
  3539.  
  3540. (Actually, all of the above should be calculated by the compiler, and the
  3541. value should be put into the expression; but the calculations I give are the
  3542. method to use if the constants were variables.)
  3543.  
  3544.  
  3545. --- Msg V3.2
  3546.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  3547.  * Tossed by SFToss v1.00b on 92/03/20  11:34:22
  3548.  
  3549. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3550.  
  3551. Conference 4
  3552. Date       03-20-92 04:49:32
  3553. From       Trevor Carlsen
  3554. To         Daniel Walton
  3555. Subject    Re: BLOCKWRITE QUESTION.
  3556.  
  3557.  
  3558.  
  3559.  DW>  I haven't had a chance to test it yet, but I read a
  3560.  DW> paragraph in "Mastering Turbo Pascal 6"  by Scott D. Palmer
  3561.  DW> that says otherwise. It says, " One potential pitfall, if
  3562.  DW> you do use Blockwrite, is that it inserts an end-of-file
  3563.  DW> character (Ctrl-Z) at the end of a block. This means that if
  3564.  DW> a block ends in the middle of an existing file and you look
  3565.  DW> for the end of the file by using the EOF function, your
  3566.  DW> program will stop at the end of the block." Am I just
  3567.  DW> reading this wrong or what?
  3568.  
  3569. I would suggest that, if that is a direct quote, you are reading it correctly.
  3570.  The trouble is it is very wrong!  If the man can make a statement that is
  3571. a stuff up of that magnitude, it does not auger well for the quality of the
  3572. rest of the book.
  3573.  
  3574. I think "Mastering Turbo Pascal 6" is also the title of a book by Tom Swan
  3575. which has received rave reviews here.  I have not seen it but other books
  3576. by him are of excellent standard.
  3577.  
  3578. TeeCee
  3579.  
  3580. --- TC-ED   v2.01  
  3581.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  3582.  * Tossed by SFToss v1.00b on 92/03/21  11:38:09
  3583.  
  3584. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3585.  
  3586. Conference 4
  3587. Date       03-20-92 05:15:07
  3588. From       Trevor Carlsen
  3589. To         Andrew Broughton
  3590. Subject    Variable-Length Records
  3591.  
  3592.  
  3593.  
  3594.  AB> I have a database that is about 4.5 megs, containing over
  3595.  AB> 250,000 one-field entries. The database is already sorted in
  3596.  AB> alphabetical order...
  3597.  
  3598. Mmmm... I think that (sorted in alpha) is the little bit of vital information
  3599. previously not given :-). (You previously stated that it was sorted but not
  3600. how it was sorted.)
  3601.  
  3602.  AB> An index file would be too big, and a memory variable would
  3603.  AB> be impossible. The conclusion that I've come to so far is to
  3604.  AB> treat the file as if it contained equal-length records, then
  3605.  AB> start the binary search. If the file pointer lands in the
  3606.  AB> middle of a record, then Inc or Dec it until it gets to the
  3607.  AB> beginning of the record.
  3608.  
  3609. Here is an idea that would make your search *very* much easier and faster.
  3610.  It would also involve an index file of fixed size (52728 bytes). 
  3611.  
  3612. First create a "mediumint" type! (Necessary so that the array will fit in
  3613. one segment)
  3614.  
  3615. type
  3616.   MediumInt = array[0..2] of byte;
  3617.  
  3618. Create an array['A'..'Z','A'..'Z','A'..'Z'] of MediumInt, then read each record
  3619. of the file and store the offset of each record whose first three characters
  3620. differ from the previous records first three characters in this array.  For
  3621. the example we'll call this array - "Offsets".
  3622.  
  3623. Then to find the first name SMITH, all that is required is to -
  3624.   seek(f,Medium2Long(Offsets[name[1],name[2],name[3]]);
  3625.  
  3626. You can then either sequentially search all records from that offset on until
  3627. the appropriate one is found or not found (by reaching SMJ) or you can BlockRead
  3628. the whole file between SMI and SMJ and do a Boyer-Moore search of the buffer.
  3629.  The latter method would mean you would find the record you want in under
  3630. 1/10th second if all records starting "SMI" were less than one segment in
  3631. size.  
  3632.  
  3633. If you want code for using a "mediumint" I will post it.
  3634.  
  3635. TeeCee
  3636.  
  3637.  
  3638.  
  3639. --- TC-ED   v2.01  
  3640.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  3641.  * Tossed by SFToss v1.00b on 92/03/21  11:38:09
  3642.  
  3643. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3644.  
  3645. Conference 4
  3646. Date       03-20-92 06:06:38
  3647. From       Trevor Carlsen
  3648. To         Andrew Broughton
  3649. Subject    Variable-Length Records
  3650.  
  3651.  
  3652.  
  3653. My previous message to you contains a small error.  In the line that reads -
  3654.  
  3655. "...read each record of the file and store the offset of each record..."
  3656.                                                          ^^^^
  3657. Change that to -
  3658. "...read each record of the file and store the offset of the first record..."
  3659.                                                          ^^^^^^^^^
  3660.  
  3661. Sorry 'bout that! 
  3662.  
  3663. TeeCee
  3664.  
  3665. --- TC-ED   v2.01  
  3666.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  3667.  * Tossed by SFToss v1.00b on 92/03/21  11:38:10
  3668.  
  3669. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3670.  
  3671. Conference 4
  3672. Date       03-20-92 08:04:55
  3673. From       Trevor Carlsen
  3674. To         Steve Sparks
  3675. Subject    Re: Hacking the Network
  3676.  
  3677.  
  3678.  
  3679. Final WARNING:
  3680.  
  3681. This thread has no place in this conference.  Take it elsewhere immediately.
  3682.  
  3683. If you, or anybody else, wish to reply to this message do so by netmail only.
  3684.  
  3685. Trevor Carlsen
  3686. Moderator.
  3687.  
  3688. --- TC-ED   v2.01  
  3689.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  3690.  * Tossed by SFToss v1.00b on 92/03/21  11:38:11
  3691.  
  3692. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3693.  
  3694. Conference 4
  3695. Date       03-20-92 08:19:02
  3696. From       Trevor Carlsen
  3697. To         Ashley Nichols
  3698. Subject    Pascal 6.0
  3699.  
  3700.  
  3701.  
  3702.  AN> How do you write a linked list to disk? And how can you tell
  3703.  AN> the differnce between the different ones? I can insert
  3704.  AN> things into the list, but yet I can't tell the difference
  3705.  AN> between them. I don't know anything about linked lists, and
  3706.  AN> so I would like all the help I can get!
  3707.  
  3708. Obviously the pointer parts of a linked disk mean nothing if written to disk.
  3709. So just traverse the list writing the relevant parts of each record to a disk
  3710. record.
  3711.  
  3712. TeeCee
  3713.  
  3714. --- TC-ED   v2.01  
  3715.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  3716.  * Tossed by SFToss v1.00b on 92/03/21  11:38:11
  3717.  
  3718. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3719.  
  3720. Conference 4
  3721. Date       03-20-92 08:21:20
  3722. From       Trevor Carlsen
  3723. To         Gene Buckle
  3724. Subject    Re: Bbs Source.. / Range Checking
  3725.  
  3726.  
  3727.  
  3728.  GB> The variable is being set to false as the first command in
  3729.  GB> the main begin..end clause.  I'm not terribly concerned
  3730.  GB> about it right now as I don't have the time to work on the
  3731.  GB> program anymore.  Thanks for the info.  Might save me some
  3732.  GB> time on a later project.
  3733.  
  3734. OK.  So the rcs variable is somehow getting trashed. Watch it in the debugger.
  3735.  
  3736. TeeCee
  3737.  
  3738. --- TC-ED   v2.01  
  3739.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  3740.  * Tossed by SFToss v1.00b on 92/03/21  11:38:11
  3741.  
  3742. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3743.  
  3744. Conference 4
  3745. Date       03-20-92 17:41:09
  3746. From       Trevor Carlsen
  3747. To         Jud Mccranie
  3748. Subject    Re: Pascal, The Language
  3749.  
  3750.  
  3751.  
  3752.  TC> difficulties of using assembler.  The power of a language is
  3753.  TC> not how easy it is for a programmer to achieve something in
  3754.  TC> that language but how efficient and capable the language is in
  3755.  TC> executing that something.
  3756.  
  3757.  JM> Again you're equating execution speed and small size to
  3758.  JM> power...
  3759.  
  3760. No way! Execution speed and size have no real relationship to the power of
  3761. a language.  They are directly related to the efficiency of a language.
  3762.  
  3763.  JM> ...The power of the language is its power in expressing what 
  3764.  JM> we need it to.
  3765.  
  3766. Exactly - or perhaps instead of the second "power" you could say "capability".
  3767. Either way you put it better than I did.  If a language "A" cannot do something
  3768. at all and language "B" can do that something, regardless of how easy or hard
  3769. it is to achieve that, and language "B" can also do everything that language
  3770. "A" can, then language "B" is obviously the more powerful. That is the case
  3771. with TP and assembler.  Execution wise, assembler can do everything TP can
  3772. but TP cannot do everything that assembler can.  There are some things that
  3773. simply cannot be done in TP, no matter how adept you are with the language.
  3774. Therefore assembler is more powerful than TP.  As a bonus it is also more
  3775. efficient (faster) and produces much smaller executable code and makes things
  3776. safer and easier for the programmer with its strong type checking, user defined
  3777. types etc.
  3778.  
  3779. Your definition of power appears to be how easy a language makes programming
  3780. a particular task.  I think I would call that its usability.
  3781.  
  3782.  JM> If I wanted a program to run 3 times as fast I could buy a
  3783.  JM> computer 3 times as fast as what I have now for $3000.  To
  3784.  JM> code everything in assembler to make it 3x faster would take
  3785.  JM> programmer-centuries.
  3786.  
  3787. At no time would I consider suggesting that someone produces entire applications
  3788. in assembler.  That would often be tantamount to economical suicide.  All
  3789. I am suggesting is that those selected parts of a program that a user may
  3790. perceive to be slow should be critically examined - probably with the help
  3791. of a profiler - and an intelligent decision made as to whether there would
  3792. be any user benefit in recoding small critical parts in assembler.  Often
  3793. just a few lines of assembler can result in massive time savings.
  3794.  
  3795.  JM> In my big program, printing takes a long time, unless a
  3796.  JM> print spooler is used.  Otherwise, the longest it takes for
  3797.  JM> anything is about 3 seconds to read in the files at the
  3798.  JM> beginning.  Everything else that the user does takes less
  3799.  JM> than a second.  Coding in assembler isn't going to speed up
  3800.  JM> the i/o appreciably.  Everything else is fast enough as far
  3801.  JM> as the user is concerned.  Cutting that 0.5 second to 0.2
  3802.  JM> second by using assembler would take much more effort than
  3803.  JM> it is worth.
  3804.  
  3805. Fine, and I would usually agree with you there.  What I am trying to say however
  3806.  is that by not learning or using assembler, you are severely crippling yourself
  3807. by denying yourself the tools for that inevitable time when some assembler
  3808. is needed and is essential.  Make no mistake, as a professional programmer
  3809. that time *will* come, if you are not willing to take advantage of every opportu
  3810. ity, you may as well throw money down the gurgler.  
  3811.  
  3812. Just so there is no misunderstanding I reiterate, I rarely use assembler,
  3813. in fact I avoid it like the plague, I am not extra good at it, but ...,  I
  3814. would never say I don't use it or have no need of it.  I'm too fond of the
  3815. folding stuff to do that! :-)
  3816.  
  3817. TeeCee
  3818.  
  3819. --- TC-ED   v2.01  
  3820.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  3821.  * Tossed by SFToss v1.00b on 92/03/21  11:38:12
  3822.  
  3823. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3824.  
  3825. Conference 4
  3826. Date       03-20-92 08:55:48
  3827. From       Trevor Carlsen
  3828. To         Jud Mccranie
  3829. Subject    Re: Tp 6.0 Ide
  3830.  
  3831.  
  3832.  
  3833.  TC> In any testing a fundamental rule involves testing the limits,
  3834.  TC> upper and lower, of all data.  This involves stack limits, heap
  3835.  TC> limits, the whole works.  In the IDE it would be difficult, if
  3836.  TC> not impossible to do this properly.  TSRs and ISRs cannot
  3837.  TC> really be tested at all from the IDE unless you are fond of
  3838.  TC> rebooting!
  3839.  
  3840.  JM> OK, I don't know about TSRs and ISRs since I've never
  3841.  JM> written one. They must be different than app progs.  As far
  3842.  JM> as the stack and heap limits, they are larger when running
  3843.  JM> the EXE, so if you don't hit the limit in the IDE the EXE
  3844.  JM> won't either.
  3845.  
  3846. You have either misunderstood or chosen to misinterpret what I have said.
  3847. It is *essential* in testing any application that you *do* hit the design
  3848. limits.  This is really the only way you can be sure that your program will
  3849. behave as you want it too when it is working to absolute maximum.  It is not
  3850. much use to sell a program that crashes when some limit is reached because
  3851. this behaviour was never tested before release.
  3852.  
  3853. TeeCee
  3854.  
  3855.  
  3856.  
  3857. --- TC-ED   v2.01  
  3858.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  3859.  * Tossed by SFToss v1.00b on 92/03/21  11:38:12
  3860.  
  3861. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3862.  
  3863. Conference 4
  3864. Date       03-20-92 16:53:41
  3865. From       Trevor Carlsen
  3866. To         Jud Mccranie 
  3867. Subject    messages
  3868.  
  3869.  
  3870.  
  3871. cc: Greg Smith (all versions)
  3872.  
  3873.  JM> I got a message from one Greg Smith telling me to quit
  3874.  JM> sending him messages about Pascal.  But I only replied to
  3875.  JM> messages on the Pascal echo from a Greg Smith.  Is Greg #2
  3876.  JM> being confused by messages to Greg #1?
  3877.  
  3878. Almost certainly.  The name is probably not that uncommon.  We also have two
  3879. Greg Smiths here in Australia on the network. There is bound to be more than
  3880. just the two you have discovered in the US, one of whom is well liked and
  3881. well respected in this echo.  The complaint shows a real lack of BBS "sense"
  3882. and awareness of the scope of these conferences.  Treat it with the contempt
  3883. it deserves and ignore it.
  3884.  
  3885. TeeCee
  3886.  
  3887. --- TC-ED   v2.01  
  3888.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  3889.  * Tossed by SFToss v1.00b on 92/03/21  11:38:12
  3890.  
  3891. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3892.  
  3893. Conference 4
  3894. Date       03-20-92 16:53:20
  3895. From       Trevor Carlsen
  3896. To         Greg Smith 
  3897. Subject    (All GS versions!)
  3898.  
  3899.  
  3900.  
  3901. Original to Jud McCranie in reply to the following quote...
  3902.  
  3903.  JM> I got a message from one Greg Smith telling me to quit
  3904.  JM> sending him messages about Pascal.  But I only replied to
  3905.  JM> messages on the Pascal echo from a Greg Smith.  Is Greg #2
  3906.  JM> being confused by messages to Greg #1?
  3907.  
  3908. Almost certainly.  The name is obviously not all that uncommon.  We also have
  3909. two Greg Smiths here in Australia on the network. There is bound to be more
  3910. than just the two you have discovered in the US, at least one of whom is well
  3911. liked and well respected in this echo.  The complaint shows a real lack of
  3912. BBS "sense" and awareness of the scope of these conferences.  Treat it with
  3913. the contempt it deserves and ignore it.
  3914.  
  3915. TeeCee
  3916.  
  3917. --- TC-ED   v2.01  
  3918.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  3919.  * Tossed by SFToss v1.00b on 92/03/21  11:38:12
  3920.  
  3921. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3922.  
  3923. Conference 4
  3924. Date       03-20-92 09:12:23
  3925. From       Trevor Carlsen
  3926. To         Jud Mccranie
  3927. Subject    Re: C++ products
  3928.  
  3929.  
  3930.  
  3931.  JM> I haven't done any C (except for a couple of trivial progs),
  3932.  JM> but I agree with you!  In fact, I've just read several
  3933.  JM> messages advising beginners to "learn Pascal first then move
  3934.  JM> up to C".  Why not learn Pascal and stick with it????  I
  3935.  JM> guess it depends on two issues: portability and the level of
  3936.  JM> the app.
  3937.  
  3938. I reckon there is a third important one - the age and aspirations of the learner
  3939.   If, like me, s/he is a little older than most and has no ambitions to ever
  3940. become a professional programmer in the sense of entering that job market,
  3941. then it is of little consequence to learn C, as TP will do everything C does,
  3942. often faster and more efficiently. 
  3943.  
  3944. However, if the learner is young and does wish to make himself more marketable
  3945. in the job market, then a thorough grounding in as many languages as possible,
  3946. *particularly* C, is indicated.
  3947.  
  3948. TeeCee
  3949.  
  3950. --- TC-ED   v2.01  
  3951.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  3952.  * Tossed by SFToss v1.00b on 92/03/21  11:38:13
  3953.  
  3954. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3955.  
  3956. Conference 4
  3957. Date       03-20-92 10:20:13
  3958. From       Trevor Carlsen
  3959. To         Jud Mccranie
  3960. Subject    Re: TP 6 Bad design
  3961.  
  3962.  
  3963.  
  3964.  JM> I ran them from EXE files.  To be sure, I did it again.
  3965.  
  3966.  JM> TP   286   seconds
  3967.  
  3968.  JM> 5.5  N/A   22.24
  3969.  JM> 6.0  G-    22.90
  3970.  JM> 6.0  G+    22.96 (even though the EXE was 1.3% smaller
  3971.  JM> than above)
  3972.  
  3973.  JM> Of course, the 0.06 seconds isn't significant, it may be
  3974.  JM> when the tick occured.  I have R-, A+, S-, I- in the source.
  3975.  JM> One more thing, I have {$M 65520, 0, 6553600} which (in tp
  3976.  JM> 5.5) makes it 4% faster than not having the line.  I haven't
  3977.  JM> tested w/ and w/o that line in 6.0.  A+ is 2% faster, S- is
  3978.  JM> 8% faster, in my old tests.
  3979.  
  3980. Two things here surprise me.  The first is that 5.5 is faster and the second
  3981. is that the memory directive has so much effect.
  3982.  
  3983. Could you write a short demo that illustrates this first point and post it
  3984. here?  As for the second point, I cannot reproduce that nor think of why it
  3985. should be.  I'll be interested to see the code.
  3986.  
  3987. TeeCee
  3988.  
  3989. --- TC-ED   v2.01  
  3990.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  3991.  * Tossed by SFToss v1.00b on 92/03/21  11:38:13
  3992.  
  3993. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  3994.  
  3995. Conference 4
  3996. Date       03-20-92 10:28:19
  3997. From       Trevor Carlsen
  3998. To         Gavin Campbell
  3999. Subject    Screen Save
  4000.  
  4001.  
  4002.  
  4003.  GC> X:    FillChar(screensave, SizeOf(screensave));
  4004.  
  4005.  GC>   Well I had a couple problems compiling this.  First on
  4006.  GC> line six it said '=' expected.  So i fixed that.  But on the
  4007.  GC> fillchar command it said ',' needed.  I dont know how to fix
  4008.  GC> that. other than that its just what i wanted.
  4009.  
  4010. It may surprise you, but the answer is contained on page 34 of the TP6 manual
  4011. and page 268 of the TP5.5 manual.  Another surprise may be that it comes under
  4012. the explanation for the procedure FillChar.  Try reading it.
  4013.  
  4014. Another way you could help yourself is to (from the IDE) place the cursor
  4015. on FillChar and press Ctrl-F1 ...
  4016.  
  4017. TeeCee
  4018.  
  4019. --- TC-ED   v2.01  
  4020.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  4021.  * Tossed by SFToss v1.00b on 92/03/21  11:38:13
  4022.  
  4023. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  4024.  
  4025. Conference 4
  4026. Date       03-20-92 17:08:30
  4027. From       Trevor Carlsen
  4028. To         Gerald Gutierrez
  4029. Subject    Echo policemen
  4030.  
  4031.  
  4032.  
  4033.  GG>  1. Leave moderation to the moderator. Self appointed "echo policemen"
  4034.  GG>     only waste echo space and create ill-feeling.
  4035.  GG>     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  4036.  
  4037.  GG> It's greatly appreciated if you could follow this one .. it saves 
  4038.  GG> a lot of unnecessary messages.
  4039.  
  4040. Mmm... reminds me of T S Eliot's quote - "You! hypocrite lecteur! -mon semblable
  4041. - mon frere!"  which he got from Charles Baudelaire! :-)
  4042.  
  4043. TeeCee
  4044.  
  4045. --- TC-ED   v2.01  
  4046.  * Origin: The Pilbara's Pascal Centre (+61 91 732569) (3:690/644)
  4047.  * Tossed by SFToss v1.00b on 92/03/21  11:38:13
  4048.  
  4049. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  4050.  
  4051. Conference 4
  4052. Date       03-20-92 12:14:00
  4053. From       Werner Berghofer
  4054. To         Jud McCranie
  4055. Subject    Tpascal mags.
  4056.  
  4057.  
  4058.  
  4059.  
  4060.        Jud,
  4061.  
  4062.  > Could two "Greg Smith"s cause this problem?
  4063.  
  4064.        obviously there are at least two users called Greg Smith active in
  4065. this echo: the one Greg Smith from 1:104/441.8 and the other Greg Smith from
  4066. 1:110/69.  However, only the first Greg Smith seems to be interested in Pascal.
  4067.  
  4068.        W.
  4069.  
  4070. ---
  4071.  * Origin: God is real... unless declared integer. (2:310/90.100)
  4072.  * Tossed by SFToss v1.00b on 92/03/21  11:38:41
  4073.  
  4074. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  4075.  
  4076. Conference 4
  4077. Date       03-19-92 23:23:27
  4078. From       Dj Murdoch
  4079. To         David G. Edwards
  4080. Subject    Stream errors
  4081.  
  4082.  I noticed you asked your question about DOS errors in streams on Compuserve
  4083. again, and it made me curiouser.  I have the TPW source, and I think the stream
  4084. code there is very close (identical?) to the stream code in TV.  In all the
  4085. cases I checked, with the possible exception of GetSize (where something weird
  4086. was going on), the Error method gets called immediately after the DOS call
  4087. that fails.  It has Info set to the value returned by DOS in AX, which is
  4088. the error code.  It looks to me as though it would always be safe to ask DOS
  4089. for extended error information at that point.
  4090.  
  4091. You could probably also ask for it in the StreamError global procedure, but
  4092. there's a chance that some stream's Error method would already have messed
  4093. with it before you got a chance to see it.  If you're writing this for your
  4094. own use, I'd do it that way, and make a note to myself to be careful when
  4095. overriding Error.
  4096.  
  4097. --- Msg V3.2
  4098.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  4099.  * Tossed by SFToss v1.00b on 92/03/21  11:40:27
  4100.  
  4101. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  4102.  
  4103. Conference 4
  4104. Date       03-20-92 08:48:45
  4105. From       Dj Murdoch
  4106. To         Jud Mccranie
  4107. Subject    Re: TP 6.0 IDE memory
  4108.  
  4109.   DM> It's probably too late to make any difference now, but what
  4110.  DM> sort of changes were you looking for?
  4111.  
  4112.  JM> Back to 5.5-style IDE, obviously.
  4113.  
  4114. No, you misunderstood my question.  What sort of improvements on 5.5 were
  4115. you looking for?
  4116.  
  4117. --- Msg V3.2
  4118.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  4119.  * Tossed by SFToss v1.00b on 92/03/21  11:40:27
  4120.  
  4121. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  4122.  
  4123. Conference 4
  4124. Date       03-20-92 08:49:44
  4125. From       Dj Murdoch
  4126. To         Dale Frakes
  4127. Subject    Re: Turbo Vision Questions...
  4128.  
  4129.   > And apart from the TStream class and its descendants, and the
  4130.  > TStringList, and the TResourceFile.  All of which are useful
  4131.  > in programs that have nothing descended from TView. 
  4132.  
  4133.  DF> Aren't TStream, TStringList, and TResourceFile all 
  4134.  DF> decendants of TObject?  I thought the only object in TV 
  4135.  DF> that isn't a decendant of TObject is TPoint (and TRect).  
  4136.  DF> Am I thinking about something in the wrong way?  Is this 
  4137.  DF> why I'm having trouble with Turbo Vision?
  4138.  
  4139. You're right.  The point is that you *can* pick and choose from the TObject
  4140. hierarchy; it's just the TView sub-hierarchy that you need to take or leave
  4141. as a whole.
  4142.  
  4143. --- Msg V3.2
  4144.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  4145.  * Tossed by SFToss v1.00b on 92/03/21  11:40:28
  4146.  
  4147. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  4148.  
  4149. Conference 4
  4150. Date       03-20-92 08:53:22
  4151. From       Dj Murdoch
  4152. To         Jud Mccranie
  4153. Subject    Re: Exponentiation (was: Are you...)
  4154.  
  4155.   JM> Great.  Did I also hear that they're going to add complex?
  4156.  
  4157. I think type complex was in the standard.  I don't know if anyone is going
  4158. to add it to a real compiler, but I'd guess VAX Pascal.  They seem to be the
  4159. big standard supporters.
  4160.  
  4161. --- Msg V3.2
  4162.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  4163.  * Tossed by SFToss v1.00b on 92/03/21  11:40:28
  4164.  
  4165. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  4166.  
  4167. Conference 4
  4168. Date       03-20-92 08:55:52
  4169. From       Dj Murdoch
  4170. To         Terry Hughes
  4171. Subject    Re: Binary Tree Linked L
  4172.  
  4173.   TH> In the circles that I travel (database toolbox vendors and
  4174.  TH> programmers) B-Tree is generally understood to mean Bayer-Tree
  4175.  TH> -- Bayer being one of the inventors of this particular
  4176.  TH> structure. It's different from a binary tree in that each node
  4177.  TH> contains pointers to many subnodes, rather than just left/right
  4178.  TH> subnodes and every node must be at least half-full. I believe a
  4179.  TH> Bayer-Tree implies balancing as well but I don't have my
  4180.  TH> reference here right now to check.
  4181.  
  4182. Thanks.  I think I've heard that before, but I forgot it.  Why don't they
  4183. just call them Bayer-Trees?
  4184.  
  4185. --- Msg V3.2
  4186.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  4187.  * Tossed by SFToss v1.00b on 92/03/21  11:40:28
  4188.  
  4189. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  4190.  
  4191. Conference 4
  4192. Date       03-20-92 18:19:30
  4193. From       Dj Murdoch
  4194. To         Jud Mccranie
  4195. Subject    Re: Obsolete Pascal??
  4196.  
  4197.   JM> Interestingly, though, BASIC and FORTRAN have gone through such
  4198.  JM> radical changes that old versions won't even come close to compiling.
  4199.  JM> Pascal isn't that way, indicating that it was designed better.
  4200.  
  4201. Well, standard Pascal won't compile in TP, whereas Fortran 66 compiles fine
  4202. in Fortran 77 and probably in the latest standard as well.  I think Fortran
  4203. is a much worse design than Pascal, but it has a lot of staying power.
  4204.  
  4205.  
  4206. --- Msg V3.2
  4207.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  4208.  * Tossed by SFToss v1.00b on 92/03/21  11:40:28
  4209.  
  4210. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  4211.  
  4212. Conference 4
  4213. Date       03-20-92 20:58:23
  4214. From       Dj Murdoch
  4215. To         Jud Mccranie
  4216. Subject    Re: How to group procs in units
  4217.  
  4218.   JM> How do you think it is best to organize your units?  That is, should
  4219.  JM> you
  4220.  
  4221.  JM> 1. group procs into units according to functionality (e.g. all
  4222.  JM>    file handling together, all reports together, all editing
  4223.  JM>    together, etc)
  4224.  
  4225.  JM> 2. group according to level (ones that don't call any other procs
  4226.  JM>    together, all procs that call only ones in the previous unit,
  4227.  JM>    etc)
  4228.  
  4229.  JM> 3. Some combination of these two
  4230.  
  4231.  JM> 4. Something else
  4232.  
  4233. Most of my programs use two quite different kinds of units.  There are the
  4234. high level ones, that are specific to each program, and the low level service
  4235. units, which are shared among many programs.  The organization is different
  4236. for the two kinds.
  4237.  
  4238. The high level units should be organized according to the organization of
  4239. the program.  If a program does three "things", then there should be three
  4240. high level units, and perhaps a fourth which dispatches requests to the other
  4241. three.  These units will handle all the high level functionality involved
  4242. in their particular task, and will call on the low level units to actually
  4243. carry out the tasks.  If more than one task creates reports, then I may well
  4244. put the report generating capability separately into each of them.  On the
  4245. other hand, if the reports are closely related, and should have the same appeara
  4246. ce, I'll make an intermediate level report writing unit, and the two high
  4247. level units will both make calls to it.
  4248.  
  4249. The low level units should be organized strictly according to functionality.
  4250.  If I want to do something with a mouse, I'd expect to find it in the Mouse
  4251. unit.  Something with strings should be in the Strings unit.  (In actual fact,
  4252. the names for these are OPMouse and OPString :-).  
  4253.  
  4254. The common thing tying both approaches together is the rule:  Every unit in
  4255. a program should have a one line description.  If I can't describe what a
  4256. unit does in one line, then there's something wrong with the way that unit
  4257. is designed.  The different lines should be distinctive, too - it shouldn't
  4258. be hard to guess where a particular function/procedure/variable would be,
  4259. just from scanning a list of the one-liners.  If it could be in either of
  4260. two units, then they should probably be merged, or at least rearranged, so
  4261. that the distinction between them is clearer.
  4262.  
  4263. In fact, the rule above is just a special case of the general rule:  *everything
  4264.  in a program should have a one line description.  If I can't summarize what
  4265. something is in a single line, then it means I don't have a clear idea, and
  4266. it needs work. 
  4267.  
  4268. --- Msg V3.2
  4269.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  4270.  * Tossed by SFToss v1.00b on 92/03/21  11:40:29
  4271.  
  4272. ▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄
  4273.  
  4274. Conference 4
  4275. Date       03-20-92 21:16:36
  4276. From       Dj Murdoch
  4277. To         Daniel Walton
  4278. Subject    Re: BLOCKWRITE QUESTION.
  4279.  
  4280.   DW>  I haven't had a chance to test it yet, but I read a 
  4281.  DW> paragraph in "Mastering
  4282.  DW> Turbo Pascal 6"  by Scott D. Palmer that says otherwise. It says, " One 
  4283.  
  4284.  DW> potential pitfall, if you do use Blockwrite, is that it 
  4285.  DW> inserts an end-of-file
  4286.  DW> character (Ctrl-Z) at the end of a block. This means that if a block ends
  4287.  
  4288.  DW> in the middle of an existing file and you look for the end 
  4289.  DW> of the file by using
  4290.  DW> the EOF function, your program will stop at the end of the block."
  4291.  DW> Am I just reading this wrong or what?
  4292.  
  4293. If that's an exact quote, then it's nonsense.  TP 6 doesn't put a Ctrl-Z in
  4294. when it closes a file, and certainly doesn't put one in at the end of a block
  4295. written by BlockWrite.
  4296.  
  4297. --- Msg V3.2
  4298.  * Origin: Murdoch's Point: Waterloo, Ontario, Canada (1:221/177.40)
  4299.  * Tossed by SFToss v1.00b on 92/03/21  11:40:29
  4300.